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Appendix  A 

HELPFUL  SOURCES 

This  iq)pendix  provides  souroes  to  hdp  the  Dq)artment  of  the  Navy  (DON)  Program 
Manager  become  knowledgeable  about  Ada-reh^  issues.  Informaticm  is  provided  on 
several  Government  sources,  including  the  Ada  Information  Qearinghouse  (AdalC), 
which  is  qxxiaQred  by  die  Ada  Joint  Program  Office  (AJPO)  and  other  sources.  Tte 
sources  listed  are  not  exhaustive,  and  the  informatim  r^arding  these  sources  may  have 
changed  since  die  publication  of  this  document.  DON  does  not  endorse  these  sources, 
and  Dqiartment  of  Deienae*s  (DOD’s)  use  of  Ada  does  not  imply  in  any  manna*  that  die 
DOD  endorses  or  favors  any  commeiciai  Ada  product.  These  products  are  listed  to 
inform  Program  Managers  of  what  is  available.  Program  Managers  must  use  their  own 
judgments  about  the  value  of  the  services.  Additional  sources  can  be  added  to  this  list 
for  future  editions  of  this  guide  by  coitacting  the  DON  Ada  Rqiresentative. 

A.1  GOVERNMENT  SOURCES 

Government  sources  are  organized  into  seven  cat^oiies:  oiganizadcms,  training, 
publications,  bulletin  boards,  rqmsitories,  conferences  and  qiecial  interest  groups,  and 
operational  devdopment  support  tools.  The  type  of  information  contained  in  each  of  die 
cat^oties  is  as  follows: 

•  Oiganizatknis— DOD,  DON,  and  Marine  Corps  organizations  that  focus  on  Ada 
policy,  tedinical  guidance,  and  programs  with  DON-wide  s^licability 

•  Traiidiig— sources  of  training  and  informoion  about  training  for  various  types  of 
poscxuid 

•  Publicatioiis— sources  of  newdetters  and  otha  publications 

•  Bulletin  Boards— sources  that  maintain  a  iniblic  bulletin  board  directed  at  the  Ada 
community 

•  Repositories— scHirces  of  reusable  components  and  libraries 

•  Conferences  and  Special  Interest  Groups— information  on  r^ularly  scheduled 
e^iositions,  workshops,  and  symposia  as  well  as  conferences 

•  Operational  Devetopment  Support  Tools— information  on  environmoits  and  tools 
currendy  used  by  the  DOD  community 
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The  amount  of  Ada>related  infonnation  available  from  these  sources  is  too  vast  to 
reproduce  in  this  appendix.  However,  an  address,  telephone  number,  electronic  mail 
address  (if  available),  and  short  description  are  provided  for  each  source.  Ofloi,  the 
easiest  way  to  obtain  information  from  these  sources  is  by  electronic  mail,  but  contact 
by  mail,  tdephone,  or  facsimile  is  also  possible. 

A.1.1  Organizations 

Ada  Joint  Program  Office 
1211  South  Fern  Street 
Room  C107 
Arlington,  VA  22202 
(703)  614-0209 
DSN:  224^)208 

The  Ada  Joint  Program  Office  (AJPO),  which  consists  of  a  dq)uty  director  from  each 
Service  and  a  chairperson,  is  responsible  for  managing  the  effort  to  implement, 
introduce,  and  provide  life-cycle  support  for  the  Ada  programming  language.  The  AJPO 
^nsors  AdalC,  a  primary  source  of  Ada  information. 

Ada  9X  Project 
Project  Manager 
Phillips  LaboratoryATES 
3SS0  Aberdeen  Avenue,  S.E. 

Kirtland  AFB,  NM  87117-5776 
(505)  846-0461 

Internet:  anderson@plk.af.mil 

This  project  is  responsible  for  revisions  to  the  American  National  Standards 
Institute/Military  Standard  (ANSI/MIL-STD)-1815A  to  reflect  current  essential 
requirements  with  minimum  negative  impact  and  maximum  positive  impact  on  the  Ada 
community. 

Ada  Board 

Ada  Joint  Program  Office 
1211  South  Fern  Street 
Room  C107 
Arlington,  VA  22202 
(703)  614-0209 
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The  Ada  Board  provides  AJPO  with  balanced  advice  and  "formation  rni  the  technical 
aq)ects  related  to  official  interpretations  of  the  Ada  langu..ge  standard  and  on  issues 
assocuUed  with  Ada  validation  and  software  ravironment  activities. 

Ada  Infomiation  Clearinghouse 
AdalC 

P.O.  Box  46S93 
Washington,  D.C.  200S0-6S93 
(703)  685-1477 

1-800-232-4211  (1-800-AdaIC-ll) 

Internet:  adainfo®ajpo.sei.cmu.edu 
FAX:  (703)685-7019 
CompuServe:  70312,3303 

Ada  Joint  Program  Office 
OUSD(A)/DDRE/AJPO 
Room  3E118,  The  Pentagon 
Washington,  D.C.  20301-3081 
(703)  614-0215 
FAX:  (703)685-7019 

The  latest  information  about  Ada  is  available  to  you  free  of  charge  from  AJPO’s  Ada 
Information  Clearinghouse  (AdalC).  The  AdalC  makes  available  information  on  a 
variety  of  topics  ranging  from  the  use  of  Ada  within  DOD  and  industry  to  tools  and 
compUers  for  Ada  developers,  and  from  DOD  policies  regarding  Ada  to  reusable  Ada 
software. 

The  AJPO  sponsors  the  AdalC.  The  AJPO  is  re^nsible  for  informing  the  community 
about  Ada,  Mutating  the  language’s  implemoitation  in  the  services,  and  maintaining  the 
integrity  of  the  language. 

The  telq)hone  hotline  numbers  are  1-800-232-4211  outside  the  Washington,  D.C.  area, 
and  (703)  685-1477  in  the  Washington,  D.C.  area.  For  answers  to  your  Ada  questions, 
call  tte  AdalC,  Monday  through  Friday,  from  8:00  a.m.  to  5:00  p.m.,  Eastern  Time. 

Ada  Validation  Office 

Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria,  VA  22311 
(703)  845-6639 
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This  office  implements  compiler  validation  policy  and  oversees  development  of  the  Ada 
Compiler  Validation  Oynbility  (ACVC). 

National  Institute  of  Standards  and  Technology 
Software  Standards  Validation  Group 
Building  225,  Room  A-266 
Gaithersburg,  MD  20899 
(301)  975-3274 
Attn.:  Arnold  Johnson 

The  National  Institute  of  Standards  and  Technology  (NIST)  provides  Federal  Information 
Processing  Standards  (FIPS)  for  the  Ada  language.  NIST  also  is  an  Ada  validation 
facility  and  coordinates  with  AJPO  for  conformance  testing,  policies,  and  procedures. 

DON  Software  Executive  Official 

Commander,  Naval  Information  System  Management  Center 

Crystal  Plaza  5,  Room  334 

2211  Jefferson  Davis  Highway 

Arlington,  VA  22202 

(703)  602-2103 

The  DON  Software  Executive  Official  (SEO)  is  the  point  of  contact  for  all  DON  software 
and  software-related  issues. 

DON  Ada  R^resentative 
AST  Software  and  Systems 

Naval  Information  System  Mans^ement  Cent^  (NISMC) 

Building  166,  Washington  Navy  Yard 
Washington,  D.C.  20374 
(202)  433-4903/3499 

This  office  is  the  point  of  contact  for  all  Ada  and  Ada-related  issues. 

Space  and  Naval  Warfare  Systons  Coumuind 
Code  224-1 
5  Crystal  Park 
Suite  700 

Washington,  D.C.  20363-5100 
(703)  602-9188 
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The  Space  and  Naval  Wai£ue  Systems  ommand  (SPA WAR)  is  the  point  of  contact  for 
DOD-STD-2176A,  Defense  System  oftware  Development;  computa-  resources 
management  and  interface  standards  for  we^)on  systems  sq[}plications  (Secretary  of  the 
Navy  Instruction  [SECNAVINST]  S200.32A  and  Secretary  of  Ae  Navy  Note 
[SECNAVNOTE]  5200);  and  Navy  rqnesentation  on  the  Joint  Logistics  Commanders 
Joint  Policy  Coordinating  Group  <m  Computer  Resources  Management  (JLC-JPCG- 
CRM). 

Next  Generation  CcHnputer  Resources 

Space  and  Naval  Warfare  Systems  Command 
Code  311-2 
5  Crystal  Park 
Suite  700 

Washington,  D.C.  20363-5100 
(703)  609-9096 

This  office  is  the  point  of  contact  for  all  next  generation  computer  issues. 

Commander,  Naval  Computer  and  Telecommunications  Command 
(COMNAVCOMTELCOM) 

Ada  Program  Manager 

4401  Massachusetts  Avenue,  N.W. 

Washington,  D.C.  22036-5460 
(202)  282-0221 
DSN:  292-0221 
FAX:  (202)282-2684 

This  command  is  the  headquarters  for  the  Naval  Computer  and  Telecommunications 
Stations  (NCTTSs).  Throu^  the  Ada  Technical  Support  Bulletin  Board,  the  Naval 
Computer  and  Tdecommunications  Command  (NAVCOMTELCOM)  provides  support 
for  Ada  projects  and  technical  information  to  the  Ada  community  at  large.  NCTC  chairs 
the  AdaSAGE  Configuration  Management  Board,  manages  the  Navy-wide  Reuse  Centm*, 
and  publishes  CHIPS. 

Commandant  of  the  Marine  Corps 
Director  (CTAE-13) 

MARCOR  COMTELACT 
3255  Meyers  Avmiue 
Quantico,  VA  22134-5048 
(703)  640-4897 

Internet:  dq)asquale®mqgl.usmc.mil 
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This  source  is  the  primary  point  of  contact  for  Marine  Corps  Ada  program  devdq>ment. 

Naval  Center  for  Cost  Analysis 

Head,  Automated  Information  Systems  Division 

Pentagon 

Room  4AS38 

Washington,  D.C.  20350-1100 
Attn.:  Stephen  Gross 
(703)  746-2342 
DSN:  286-2342 
FAX:  (703)  746-2390 

The  Naval  Center  for  Cost  Analysis  (NCA)  was  established  6  August  1985  by  decision 
of  the  Secretary  of  the  Navy  with  the  following  mission:  ”To  provide  indepoident  cost 
and  financial  analyses  to  support  the  Secretary  of  the  Navy  .  .  .  [and  to]  Ensure 
credible  cost  estimates  of  the  resources  required  to  develop,  procure,  and  operate  military 
systems  and  forces  in  support  of  planning  programming,  budgeting  and  acquisition 
management." 

NCA  is  a  field  office  of  the  Assistant  Secretary  of  the  Navy  (Financial  Management). 
It  is  located  in  the  Crystal  City  area  of  Arlington,  Virginia,  the  Pentagon.  NCA 
supports  the  Office  of  the  Secretary  of  Defense  (OSD)  in  satu/ying  Title  10  U.S.  Code 
$2434,  which  requires  independent  life-cycle  cost  estimates,  including  the  cost  of 
research  and  development,  procurement,  and  operations  and  support  of  major  weiqxnis 
systems  such  as  ships,  aircraft,  missiles,  and  dectronic  systems.  NCA  also  cmducts 
financial  analyses  of  defense  contractors  and  economic  an^yses  of  acquisition  issues. 

Software  Technology  Support  Center 
Ogden  Air  Logistics  Center 
nSAC 

HillAFB,  UT  84056 

The  Software  Technology  Support  Center  (STSC)  acts  as  a  focal  point  for  the  U.S.  Air 
Force  on  software  tools,  methods,  and  environments.  Its  activities  include  a  bull^ 
board,  an  annual  software  conference,  a  monthly  newsletter,  consulting  services,  rqwrts 
on  various  software  topics,  information  on  software  rq)Ositories,  and  other  software 
support  services.  The  STSC  provides  quantitative  evaluations  of  technology,  tailored  to 
qie^c  customer  requirements,  on  a  fee-for-service  basis.  The  STSC  also  has  several 
tedmology  insertion  projects  and  is  working  directly  with  q)ecific  customers  in  selecting 
new  technology  and  inserting  the  technology.  Among  the  rqxnts  on  software  topics  are 
a  software  manager’s  guide,  a  project  managemoit  technology  report,  a  reengineering 
technology  report,  and  tool  rqwrts  on  various  domains  from  Computer-Aided  Software 
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Engiiieering  (CASE)  tools  to  documentation  tools.  Information  cm  software  iqmsitories 
is  a  special  examination  being  conducted  by  the  STSC.  It  will  result  in  a  rqxnt  and  a 
numba  of  activities  with  various  customers. 

Software  Engineering  Institute 
Customer  Relations 
Carn^e-Mdlcm  University 
Pittsburgh,  PA  15213-3890 
(412)  268-5800 
FAX:  (412)268-5758 

The  Software  Engineering  Institute  (SEI)  is  a  Federally  Funded  ^ch  and 
Development  Center  (FFRDC)  sponsored  by  DOD  through  the  Advanc  eseaich 
Projects  Agency  (ARPA).  The  SEI  provides  leadership  in  advancing  the  «utte  of  the 
practice  of  software  engineering  to  improve  the  quality  of  systems  that  depend  on 
software.  The  SEI’s  four  areas  of  focus  are  software  process,  software  risk  management, 
real-time  distributed  systems,  and  software  otgineering  techniques.  To  increase  the 
number  of  highly  qualified  software  engineers,  the  SEI  also  seda  to  improve  software 
engineering  education  within  academia.  Government,  and  industry. 

In  response  to  computer  security  threats,  ARPA  established  the  (^mputer  Emergency 
Reqm^  Team  (CERT)  Coordination  Center  at  the  SEI  to  support  Internet  users.  The 
monbers  of  the  CERT  Cemrdination  Center  work  with  the  Internet  user  community  and 
technology  producers  to  address  and  prevent  computer  emergencies. 

To  accelerate  die  dissemination  of  new  technologies  and  methods,  the  SEI  offers  U.S. 
organizations  from  academia.  Government,  and  industry  several  methods  of  interacting 
with  the  institute.  Information  on  the  subscriber  program,  technical  reports,  cmitinuing 
education  courses,  and  symposia  may  be  obtained  by  calling  or  writing  to  the  Customer 
Relations  Office. 

Software  Technology  for  Adaptable,  Reliable  Systems  (STARS) 

801  North  Randolph  Street,  Suite  400 
Ariington,  VA  22203 
(703)  351-5300 

Internet:  (for  newsletter)  newsletter®stars.ballston.paramax.com 
(for  ASSET)  ^ARSBBS@source.asset.com 
INFC)®source.asset.com 
For  more  information: 

Jod  Trimble— E-mail  trimble@stars.ballston.  paramax.com  or  above  address 
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The  STARS  Progiam  is  a  major  ARPA/Software  and  Intelligent  Systems  Technology 
Office  (SISTO)  effort  to  provide  more  capable,  efficient  and  productive  methods  of 
developing  software  for  DOD.  STARS’  goals  are  to  (1)  improve  productivity;  (2) 
improve  quality  and  reliability;  (3)  promote  development  and  application  of  reusable 
software;  and  (4)  promote  adaptability,  evolvability,  and  interoperability  through  the  use 
of  standard  inter^ices  and  open  architectures,  both  of  the  ai^lication  software  and  of  the 
Software  Engineering  Environments  (SEEs),  which  support  that  implication  software. 

The  technology  areas  STARS  supports  include  SEE  frameworks,  software  reuse 
mechanisms,  and  tailorable  software  process  models.  STARS  includes  the  national  Asset 
Source  for  Software  Engineering  Technology  (ASSET)  software  reuse  library  effort. 

STARS  maintains  an  affiliates  program  to  provide  an  opportunity  for  the  DOD  software 
community  to  participate  in  STARS  technical  activities.  The  three  levels  of  affiliates 
(e.g.,  individual  representatives  of  Govemmmt  agencies,  universities,  vendors)  are  as 
follows: 

•  Information  affiliates  who  receive  the  STARS  newsletter,  attend  STARS 
conferences,  (STARS  9X),  have  access  to  the  STARS  bulletin  board,  and  attend 
STARS  technology  demonstrations  at  the  STARS  Technology  Center 

•  Technology  transition  affiliates  who  attend  technical  exchange  working  group 
meetings;  voluntarily  participate  in  selected  receptor  organizations;  and  are 
involved  in  alpha/beta  testing,  feedback,  lessons  learned,  and  product  evolution 

•  Prime  affiliates  who  work  directly  with  STARS  prime  contractors  in  relevant 
technical  activities  such  as  technology  transition,  production  evaluation,  and  tool 
development. 

The  parent  sponsoring  organizations  are  responsible  for  labor,  travel,  and  other  expenses 
associated  with  participating  in  the  affiliates  program. 

A.1,2  Training 

Ada  Language  System/Navy 
ALS/N  Training 
NCCOSC  RDTE  DIV  924 
53560  HuU  Street 
San  Diego,  CA  92152-5800 
(619)  553-0949 
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Traini'::*  provided  at  this  source  includes  Ada  Language  System/Navy  (ALS/N)  courses 
pcrtai;..ng  to  Ada/M  (UYK-44(V)  ta^et),  Ada  L  (AN/UYK-43(V)),  PPI  (AN/AYK-14 
(V)  target),  and  Common  Ada  Baseline/l^ject  Support  Environment  (CAB/PSl^  tools 
(a  VAX/VMS  host  with  associated  PSE  tools).  Training  is  available  by  request  in 
conjunction  with  ALS/N  quarterly  meetings,  and  on-site  training  is  available. 

Ada  Software  Engineering  Education  and  Training  Team 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria,  VA  22311 
Attn.:  Cathryn  McDonald 
(703)  845-6626 
(719)  472-3131 
(202)  282-0833 

The  Ada  Software  Engineering  Education  and  Training  (ASEET)  team  is  composed  of 
rqnesentatives  from  the  Army,  Air  Force,  Navy,  Marine  Corps,  other  DOD  agencies, 
and  academia.  The  team  conducts  workshops  and  symposia  for  Ada  educators  within 
DOD  and  academia  and  coordinates  the  activities  of  DOD  organizations  engaged  in 
meeting  the  Ada  education  and  training  needs.  The  team  is  also  available,  as  funding 
permits,  to  present  1-  day  or  half-day  introductory  and  advanced  tutorials  on  Ada  and 
software  engineering.  It  also  conducts  an  annual  Ada  symposium  that  focuses  on 
education  and  training  issues.  An  ASEET  resource  library  of  educational  materials  is 
located  at  AJPO.  ASEET  also  has  established  an  Ada  Materials  Library  that  contains 
copies  of  all  team-developed  tutorials  and  many  other  Ada  documents  and  textbooks. 

Team  members  are  located  all  across  the  continental  United  States  and  could  serve  as 
local  resources  to  answer  questions  on  Ada  or  to  direct  inquiries  to  non-local  sources. 

The  team  has  tri-Service  representation  on  four  working  groups  that  address  education 
and  training  on  requiremrats,  courseware,  profesaonal  development,  and  coordination. 
Major  tasks  include  the  following: 

•  Identifying  education  and  training  requirements  within  DOD 

•  Conducting  Ada  research  projects 

•  Managing  Ada  course  materials 

•  Perfomung  Ada  certification  study 

•  Providing  a  database  of  ASEET  research  data  and  ftnal  rqx>rts 

•  Providing  a  DOD  focal  point  for  Ada  software  engineering  education  and  training. 
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AdaSAGE 

DqMitment  of  Energy 

Idaho  National  Engineering  Laboratory 

Idaho  Falls,  Idaho 

(208)  526^6 

The  Idaho  National  Engineering  Laboratory  (INEL)  offers  training  and  siqiport  dirough 
a  hot  line  subscription  service. 

Air  Force  Institute  of  Tedinology 

Wright  Patterson  AFB 

Ohio  45433 

(513)  255-6027 

The  Air  Fence  Institute  of  Technology  currently  teaches  the  following  courses  diat  use 
Ada  as  an  implementation  language: 

•  Introduction  to  Data  Structures  and  Program  Derign-Prindples  and 
mettuxlologies  used  to  design  and  implement  small  programs. 

•  Advanced  Information  Structures-Stru^ure  of  data  and  die  efficient  and  effective 
manipulation  (algorithms)  of  such  structures. 

•  Operating  Systems-Concqits  and  principles  of  computer  operating  systems.  The 
objective  is  to  give  the  student  an  understanding  of  operating  systems  and  the 
necessary  skills  to  evaluate  and  trade-off  desirable  features  of  operating  systems 
given  qiecific  user  and  resource  requirements. 

•  Software  Analysb  and  Derign-Examinadmi  of  the  object-oriented  paradigm  and 
the  formal  spedricatiem  of  software.  Object-oriented  design  and  formal 
qiecification. 

•  Software  Systems  Engineering-Basic  prii^ples  and  techniques  underlying  object- 
oriented  and  object-based  generation  of  software. 

•  Analyds  and  Maintenance  of  Software  Systcms-Basicprindples  and  techniques 
underlying  the  measurement  and  analysis  of  software  systems  as  well  as  the 
principles  and  techniques  underlying  the  mauntenance  of  existing  software. 

•  Algorithms  for  Parallel  Processing-Understanding  of  results  for  parallel 

design  and  analysis  and  provides  practical  insights  into  ^dent  and  effective 
implementation  on  contemporary  paralld  computational  nuichines. 
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•  Compiler  Theory  and  Implementation-Theoretical  foundauon  of  formal 
languages  and  compiler  theory. 

•  Principles  of  Embedded  Software-Mathematical  and  computer  science  principles 
for  the  specification,  design,  implementation,  and  analysis  of  embedded  software 
systems. 

•  Design  of  Fault  Tolerant  Software-Basic  mathematical  principles,  data  structures, 
and  algorithms  associated  with  the  design  of  £uilt*tolerant  software  systems. 

•  Formal-Based  Methods  in  Software  Engineering-The  mathematical  and  computer 
science  theory  used  as  the  hasis  for  devdoping  formal-based  methods  for 
qjedfying,  generating,  and  validating  or  verifying  software. 

Common  Ada  PSE  Interface  Set  (CAIS) 

CAIS-A 

Commander 

Naval  Ocean  Systems  Center 
271  Catalina  Boulevard 
San  Diego,  CA  92152-5000 
Attn.:  CAIS-A  Training  Coordinator 
(619)  553-6858 

A  5-day  training  class  is  available  that  provides  hands-on  experience  for  Ada  tool 
designers.  (Knowledge  of  the  Ada  programming  language  is  a  prerequisite.)  Training 
will  be  available  on  a  VMS  system  and  on  a  Sun  3  running  under  UNIX.  Also  available 
are  the  following: 

•  CAIS-A  Self-Study  Guide 

•  CAIS-A  Tool  Writers  Guide. 

Cmnputer  Sciences  School 

Head,  Application  Programming  Instructional  Dqnrtment  (APID) 

Marine  Corps  Combat  Development  Command  (MCCDQ 

3255  M^ers  Avenue 

Quantico,  VA  22134-5051 

(703)  640-2962 

DSN:  278-2962 

(703)  640-3759 

The  Computer  Sciences  School  (CSS)  currently  offers  the  following  Ada-related  training 
courses: 
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•  Entry-level  Ada  Programming  Course.  This  course  is  designed  for  the  student 
who  has  no  previous  programming  experience  or  training.  Programming  concepts 
and  principles  are  taught  along  with  the  basics  of  Ada  programming.  Additionally, 
subjects,  such  as  TSO,  JCL,  and  IBM  utilities,  are  taught  to  expose  students  to 
tools  they  may  need  as  programmers.  This  course  is  8  weeks  long  (41  training 
days)  and  is  offered  four  or  five  times  a  year. 

•  Ada  Programming  Course.  This  course  is  designed  to  teach  the  basics  of  the  Ada 
programming  language  to  programmers  who  are  currently  working  in  a  language 
other  than  Ada.  However,  programming  experience  is  not  a  requirement  to  attend 
the  course.  The  course  is  4  weeks  long  (20  training  days)  and  is  offoed  three 
times  a  year. 

•  Advanced  Programming  Techniques  (APT)  Course.  This  course  is  not  a  typical 
programming  course.  No  syntax  is  taught.  Instead,  the  course  teaches  software 
project  management  principles  in  conjunction  with  software  analysis  and  Object- 
Oriented  Design  (OOD)  techniques.  This  course  is  3  weeks  long  (IS  programming 
days)  and  is  offered  three  times  a  year. 

Personnel  interested  in  attending  a  course  taught  at  CSS  should  contact  the  Academics 
Officer,  Training  and  Operations  Section  ^OPS),  DSN  278-2891  or  COMM  (703)  640- 
2891,  for  specific  information  on  registering  for  a  course. 

Other  Points  of  Contact  (POCs)  are: 

•  Marine  Corps— Steve  Bruzek,  4000  MOS  Sponsor  at  DSN  241-3593  or  COMM 
(703)  614-3593 

•  Navy-Navy  DP  Detailer  at  DSN  223-3537  or  COMM  (703)  693-3537 

•  All  civilians  and  other  service  personnel— SSgt  Riegal,  Quota  Control  Manager, 
Training  and  Education  Division  at  DSN  278-3071  or  COMM  (703)  640-3071. 

Computer  Science  School 
Chief  of  Operations 
Army  Computer  Science  School 
U.S.  Army  Signal  Center  &  Fort  Gordon 
Fort  Gordon,  GA  30905 
(706)  791-2586 

Tte  Army  Computer  Science  School  currently  offi^s  a  2-week  (10-tiaining-day)  course 
in  Structured  Programming  in  Ada  for  Active  and  Reserve  Component  commissioned  and 
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warrant  officers  and  non-commissioned  officers  in  grades  E-6  and  above  and  DOD 
civilians  in  grades  GS-07  and  above,  Active-duty  or  Res£.'ve  Data  Processors  should 
contact  the  Navy  DP  Detailer,  NMPC-406.  DSN  223-3537  or  COMM  (703)  693-3537. 
Other  Navy  personnel  and  civilians  interested  in  enrolling  should  contact  Navy’s  ATTRS 
POC,  Ms.  Holder.  OPNAV-112G1,  DSN  225-8665  or  COMM  (703)  695-8665  to  enroU 
through  ATTRS,  or  contact  Chief  of  Operations,  Army  Computer  Science  School,  DSN 
780-2326  or  COMM  (706)  791-2326.  The  Army  Computer  School  also  teaches  Ada  as 
part  of  the  Systems  Automation  Officer  course,  and  students  use  Ada  in  their  software 
engineering  project. 

National  Audiovisual  Center 
8700  Edgeworth  Drive 
Capitol  Heights,  MD  20743-3701 
Attn.:  Customer  Service  Department 
(301)  763-1891 
FAX:  (301)763-6025 

A  series  of  Ada  training  tapes  sponsored  by  the  AJPO  is  available  for  purchase  through 
the  National  Audiovisual  Center  of  the  Def^ment  of  Commerce.  The  tapes  include  the 
following: 

•  Introduction  to  Ada  (3  tapes;  about  3  hours;  order  no.  A18336;  $150) 

•  Ada  from  a  Management  Perspective  (2  tapes;  about  80  minutes; 
order  no.  A18337;  $100) 

•  Software  Engineering  in  Ada  (19  tapes;  ^ut  8  hours,  20  minutes; 
order  no.  A18338;  $500). 

Additional  information  on  these  tapes  is  available  from  the  AdalC. 

National  Defense  University 

Information  Resources  Management  Curriculum 
Fort  McNair,  Washington,  D.C. 

(202)  287-9340 

Ada  is  namined  in  the  Programming  Languages  course  in  the  Advanced  Management 
Program. 

Naval  Postgraduate  School 
Monterey,  CA  93943-4444 
(408)  656-2591 


Ada  Implementation  Guide 


A-13 


SOlWCM 


The  Naval  Postgraduate  School  teaches  Ada  in  the  following  courses: 

•  Structured  Programming  with  Ada 

•  Data  Structures 

•  Software  M^odology  (the  process  of  software  development) 

•  Software  Engineoing  (formad  methods) 

•  Software  Engineering  with  Ada  (task,  real-time  issues) 

•  Computors  in  Combat  Systems 

•  Software  Tools  and  Environments. 

Software  Eo^neering  Institute 
Omn^e-Mellon  University 
Pittsburgh,  PA  1S213-3890 
(412)  268-S800 
FAX:  (412)268-5758 
Intern^:  education®sci.cmu.edu 

The  SEI  has  collected  six  software  "artifacts,"  called  EM1-EM6,  targeted  at  teaching 
software  engineering.  Artifact  EMI,  for  example,  is  a  10,0(X)-lhne  Ada  style  diecker 
packaged  with  exercises  to  teach  software  maintoiance.  SEI  also  produces  many 
technical  rqxms,  including  the  following,  which  are  highly  recommended: 

•  Ada  Adoption  Handbook:  A  Program  Manager’s  Guide 

•  Ada  Adoption  Handbook:  Compiler  Evaluation  and  Selection. 

United  States  Air  Force  Academy 
Headquarters,  USAFA/DFCS 
2354  Fairchild  Drive,  Suite  6K41 
USAFA,  CO  80840 
(719)  472-3131 
FAX:  (719)472-3338 
Internet:  dcook®kirk.  usafa.af.mil 
POC:  CAPT  David  Cook 

The  U.S.  Air  Force  Academy  teaches  Ada  to  computer  science  m^ors  in  the 
Foundations  of  Computer  Science  course.  Majors  also  use  Ada  in  the  Programming 
Languages  course  and  the  Algorithms  and  Data  Structures  course.  Additionally,  a 
2-week  course  (q)en  to  anyone  is  taught  during  the  summer  (June/July).  Space  is  limit^; 
dierdore,  early  registration  is  advised.  There  is  no  charge  for  the  course,  but  all 
students  must  pay  their  own  travel  and  per-diem  costs. 
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United  States  Air  Force  Technical  Training  School 
Keesler  Air  Force  Base 
Biloxi,  MS 
(601)  377-5379 
DSN:  597-5379 

The  U.S.  Air  Force  Technical  Training  School  teaches  Ada  in  its  Fundamentals  of  Ada 
Prryamining/Snftwaie  Engineering  couTse  and  its  Ada  Applications  Programmer  course. 


United  States  Anny  Engineering  CoOege 
Rock  Island  Arsenal 
Rock  Island,  IL  61299-7040 
Attn.:  AMXOM-RS 
(309)  782-0488/0^89/0487 

The  U.S.  Army  Er.gineering  College  provides  a  2-week  Ada  overview  free  to 
Government  employees  (Course  No.  AMEC-140).  Additionally,  four  to  five  courses  that 
run  41  training  days  per  year  include  entry-level  Ada  programming.  They  arc  currently 
developing  software  project  management  geared  toward  OOD  in  FY94. 

United  SUtes  MiUtary  Academy 
WesQ)oint,NY  10996 
(914)  938-5607 
FAX:  (914)  938-5438 
Internet:  DT2283®eecsl  .eecs.usma.edu 
POC:  CAPT  Crabtree 

The  United  States  hfilitary  Academy  first  introduces  Ada  to  computer  science  majors  in 
their  second  year  in  the  course  Analyas  of  Programming  Languages.  The  following 
year,  diey  take  Software  Engineering  widi  Ada  for  a  full  semester.  This  course 
introduces  the  students  to  software  engineering  and  focuses  on  how  Ada  supports  the 
principles  and  goals  of  software  engineering.  The  course  treats  software  engineering 
concqtts  in  detail.  The  OOD  paradigm  is  introduced  aiKi  practiced  in  programming 
assignments. 

United  States  Naval  Academy 
Computer  Science  Dq>artment 
572  Holloway  Road 
Anni^lis,  MD  21402 
(410)  267-2797/8 
FAX:  (410)267-2686 
Internet:  eun®csseiTera.scs.usna.navy.mil 


Ada  Implamantation  GuMa 


A-1B 


DSN:  281-30Cy7 
POC:  Dr.  E.K.  Park 


Hdpful  Sourcat 


The  U.S.  NavT4  Academy  teaches  Ada  to  computer  science  majors  in  their  senior  year 
in  the  Software  Engineering  and  Advanced  Software  Engineering  courses. 


All  of  the  major  Ada  compiler  vendors  have  training  available  directly  thrcnigh  their 
offices. 

A.l^  Publications 

Defense  Technical  Information  Center 
Cameron  Station 
Alexandria,  VA  22304-614S 
Attn.;  FDRA 
(703)  274-7633 

The  Defense  Technical  Information  Center  (DTIC)  distributes  documents  only  to 
military,  Government,  or  defense  contractors  who  are  rostered  users  of  DTIC.  Most 
unclassified  document*  that  are  submitted  to  DTIC  are  also  forwarded  to  the  National 
Technical  Information  Service  (NTTS)  and  are  available  to  the  public. 

National  Technical  Information  Service 
(J.S.  Department  of  Commerce 
S28S  Port  Royal  Road 
Springfield,  VA  22161 
(703)  487-4650 

NTIS,  a  self-supporting  agency  of  the  U.S.  Department  of  Commerce,  provides  free 
publications  and  directories  of  Government  datid}ases  and  software  components.  The 
Application  Portability  Profile  (APP)  and  FIPS  are  available  from  NTIS. 

Standardization  Documents  Order  Desk 
Building  4,  Section  D 
700  Robbins  Avenue 
Philadelphia,  PA  19111-5094 
Special  Assistance  Desk;  (215)  697-2179 
DSN:  442-2179 

Customer  Service:  (215)  697-2667 
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This  desk  is  the  central  distributor  of  all  rvlitaiy  standard  documents,  including  the 
standard  for  the  Ada  language  reference  mar  ual  (ANSI/MIL'STD-ISISA'IQSS).  DOD 
standards,  specifications,  handbooks,  and  data  items  can  be  ordered  by  using  the 
Telephone  Order-Entry  System  (TOES).  Access  TOES  by  calling  (215)  697-1187  (DSN 
442-1187),  Monday  through  Friday,  7:00  a.m.  to  4:30  p.m.  Eastern  Time, 

U.S.  Government  Printing  Office 
Superintendent  of  Documents 
Washington,  D.C.  20402-9371 
(202)  783-3238 

The  Superintendent  of  Documents  can  provide  the  APP. 

Ada  9X  Publications 
Phillips  Laboratoiy/VTES 
3SS0  Aberdeen  Avenue,  S.E. 

Kirtland  AFB,  NM  87117-5776 
(505)  846-0461 

The  Ada  9X  Project  Office  maintains  a  mailing  list  for  Ada  9X  documents.  To  be  placed 
on  the  mailing  list  or  to  receive  hard  copies  of  Ada  9X  documents,  send  an  E-mail 
message  to  the  following  address:  keeneyr@plk.af.mil.  For  access  to  electronic  versions 
of  Ada  9X  documents,  leave  a  message  at  action@ajpo.sei.cmu.edu 

Ada  and  C+  + 

Software  Technology  Support  Center 
Ogden  Air  Logistics  Center 
TISAC 

HUl  AFB,  UT  84056 
(801)  777-7703 

This  report  describes  studies  that  compared  Ada  to  C+-t-.  An  electronic  summary  of 
this  report  is  available  on  the  AdalC  Bulletin  Board.  The  report  is  also  available  through 
DTIC  and  NTIS. 

Ada  Information  Clearinghouse  Newsletter 
AdalC 

P.O.  Box  46593 

Washington,  D.C.  20050-6593 

1-800-232-4211 
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The  AdalC  quarterly  newsletter  contains  current  news  from  the  AJPO  about  the  Ada 
program,  Ada  confidence  reports,  and  articles  on  projects  using  Ada.  If  you  would  like 
to  receive  the  newsletter,  call  the  AdalC  and  request  a  free  subscription. 

AdaSUces 

MTTRE  Corporation 
1120  NASA  Road  1 
Houston,  TX  77057 
(713)  335-8541 

This  newsletter  is  published  by  MTTRE,  an  FFRDC.  It  is  a  product  of  the  Associaticm 
for  Computing  Machinery  (ACM)  Special  Interest  Group  on  Ada’s  (SIGAda’s) 
Performance  Issues  Working  Group  (PIWG)  and  is  available  free  of  charge. 

Ada  Software  Engineering  Education  and  Training  Public  Report 
Ada  Software  Engineering  Education  and  Training  Team 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria,  VA  22311 
Attn.:  Resource  Staff  Member 
(703)  845-6626 

ASEET  publishes  a  DOD  ASEET  Public  Report  annually.  The  rqx>rt  contains  an  update 
and  description  of  the  latest  efforts  of  the  ASEET  Team  in  identifying  training  and 
education  requirements  within  DOD  and  the  methodology  and  materials  needed  to  fulfill 
those  requirements.  Copies  of  the  rqxrrt  may  be  obtained  from  the  AdalC. 

Bridge 

Eileen  Forrester 
Managing  Editor,  Bridge 
Software  Engineering  Institute 
Cam^e-Mellon  University 
Pittsburgh,  PA  15213-3890 
(412)  268-6377 

Internet:  bridge-editor®sei.cmu.edu 

This  magazine  reports  on  SEI  projects  and  activities.  To  obtain  a  subscription,  send  a 
written  request  to  the  editor. 
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CHIPS 

^56  Fourth  Avenue,  Suite  200 

Naval  Computer  and  Telecommunications  Area  Master  Statimi,  Atlantic  (NCTAMS 
LAND 

Norfolk,  VA  23511-2199 
(804)  444-8704 
DSN  564-8704 

CHIPS  is  a  microcomputer  magazine  for  mid-level  users.  It  ctmtains  primarily  product 
reviews,  microcomputer  contract  information,  and  articles  of  genm^  interest  to  the 
microcomputer  community. 

Crosstalk,  The  Journal  of  Defense  Software  Engineering 
Software  Technology  Support  Center 
Ogden  ALC/nSE 
HiU  AFB,  UT  84056 
Attn.:  Customer  Service 
(801)  777-2237 
DSN:  458-2237 
FAX:  (801)777-8069 
Internet:  bbliss®oodis01. hill.af.mil 

Crosstalk,  The  Journal  qfDtfense  Software  Engineering,  is  published  to  ludp  improve 
die  effectiveness  of  software  used  by  DOD.  The  journal  provides  information  about 
software  tools,  methods,  and  ravironments  for  DOD  software  development  and  support 
activities,  contractors  who  develop  software  for  the  military,  and  vendors  who  produce 
CASE  tools  for  the  defense  marlret.  Crosstalk  frequendy  features  articles  on  various 
aspects  of  Ada,  from  work  on  Ada  9X  to  techniques  for  converting  from  COBOL  to  Ada 
when  reoigineering  management  information  systems.  STSC  distributes  Crosstalk 
without  charge  to  individuals  actively  involved  in  the  defense  software  development 
process.  To  request  to  be  added  to  the  mailing  list,  write  to  the  above  address.  To 
request  othm*  reports  on  software  development  tools  and  other  topics,  call  (801)  777-7703 
or  DSN  458-7703. 

DACS  Newsletter 
Barbara  Radzisz 
Editor,  DACS  Newsletter 
Data  &  Analysis  Center  for  Software 
P.O.  Box  120 
Utica,  NY  13503 
(315)  734-3696 
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DACS  Newsletter  is  the  current  awareness  publication  of  the  Data  and  Analysis  Center 
for  Software  (DACS).  It  serves  as  a  centrali^  source  for  current,  readily  available  data 
and  information  on  software  engineering  and  software  technology. 

Institute  for  Defense  Analyses 

Computer  &  Software  j&gineeiing  Division 
1801  North  Beauregard  Street 
Alexandria,  VA  22311 
(703)845-2000  (General) 

(703)845-2059  (References) 

The  institute  is  an  FFRDC  the  primary  sponsor  of  which  is  the  Office  of  the  Secretary 
of  Defense  (OSD).  All  publications  preps^  by  the  institute  are  available  through  DTIC 
or  Nns. 

High  Order  Language  Control  Facility  Ada-JOVIAL  Newsletter 
645  C-CSG/SCSL 

Wright-Patterson  AFB,  OH  45433-5707 
(513)  255-4472 
DSN  785-4472 

langed®ssl  .sews.wpafb.af.mil 

To  support  the  DOD  and  Air  Force  standardization  efforts,  informatim  is  disseminated 
about  Ada  and  JOVIAL  (J73),  standardization  and  language  control  activities,  training, 
compilers,  compilers  and  tools,  development  efforts,  applications,  and  user  services. 

NISMC  Newsletter 
Ms.  Aldnda  Wenberg 
NISMC 
BuUding  CP5 
Jefferson  Davis  Highway 
Arlington,  VA  22203 
(703)  602-2542 

This  monthly  newsletter  provides  information  on  Naval  Information  System  Management 
Center  (NISMC)  initiatives,  status  of  DON  policy,  and  upcoming  DON  activities. 
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STARS  Newslettar 

801  North  RandoljA  Street 
Suite  400 

Arlington,  VA  22203 
(703)  351-5300 

newsletter®stars.ballston.paramax.com 

The  STARS  Mwsletter  contains  articles  covering  software  reuse  technology,  software 
process  technology,  and  software  engineering  environment  ftamework  technedogy.  It  is 
published  tudee  per  year  and  is  ftee  of  charge. 

A.1.4  Bulletin  Boards 

Ada  9X  Project 
Project  Manager 
Phillips  Laboratory  ATTES 
3550  Aberdeen  Avenue,  S.E. 

Kirtland  AFB,  NM  87117-5776 
(505)  846-0461 
andaaon®plk.af .  mil 

Information  can  be  obtained  from  the  ADA  9X  Bulletin  Board  by  calling  1-800- 
Ada-9X25  or  (301)  459-8939  or  by  using  the  electronic  address  shown  above.  To  access 
die  bulletin  board  by  modem,  use  the  following  settings: 

•  Baud  rate  »  300,  1200,  or  2400 

•  Parity  »»  none 

•  Data  bits  «  8 

•  Stop  bits  s  1 

AJPO  Host  and  Ada  Information  Clearin^ouse  Bulletin  Board 
1211  South  Fern  Street 
Room  C107 
Arlington,  VA  22202 
(703)  614-0209 

The  AJPO  sponsors  two  bulletin  boards  that  serve  as  a  primary  source  for  Ada 
information.  The  igpo  host  is  accessible  electronically  on  the  Internet.  The  AdalC 
Bulletin  Board  (AdalC  BB)  is  accessible  by  modem.  Section  A.2  provides  drafts  for 
accessing  dther  bulletin  board.  The  <ypo  host  and  the  AdalC  BB  ctmtain  di^licate 
information. 
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Ada  Technical  Support  Bulletin  Board  Service 

Naval  Computer  and  Telecommunications  Area  Master  Station  Atlantic 
(NCTAMSLAND 

Norfolk,  VA 

(804)  444>7841 

DSN  564-7841 

To  access  by  modem,  use  the  following  settings: 

•  Baud  rate  «  300,  1200,  or  2400 

•  Parity  *  ntme 

•  Data  bits  »  8 

•  Stop  bits  »  1 

NAVCOMTELCOM  sponsors  an  Ada  Technical  Support  Bulletin  Board  System  (BBS) 
maintained  by  NCTAMS  LANT. 

The  main  purpose  of  the  BBS  is  to  offer  microcomputer  Ada  programmers  in  the  joint 
Services,  Government  contractors,  and  the  academic  community  a  means  for  obtaining 
answers  to  their  questions  about  the  Ada  programming  language.  The  BBS  is  targeted 
to  programmers  in  the  AIS  domain  and  to  software  creation  on  these  systems. 

The  BBS  offers  several  services: 

•  Ada  Question  and  Answer  Service.  BBS  users  can  ask  questions  about  die  Ada 
language  and  extensions  (e.g.,  pragmas)  that  might  be  included  in  a  particular 
implementation.  Additionally,  user  code  can  be  uploaded  for  evaluation.  Such 
evaluatitms  can  include  checks  for  proper  usage  of  Ada  features,  Ada  s^le,  and 
compilation  errors  that  will  not  go  away. 

•  Conquer  Vendor  Comnum  Senntx.  BBS  users  can  comment  on  DOS-based  Ada 
implementations.  Comments  can  report  dther  problems  witii  existing 
implementations  or  suggest  enhancements  that  would  benefit  the  DOS-Ada 
community.  These  commits  will  be  provided  to  tte  appropriate  compiler 
vendors.  The  goal  is  to  use  this  service  to  improve  DOS-based  Ada  comjnlers. 
A  secondary  bmietit  is  to  make  potential  users  aware  of  possible  problems  with 
particular  DOS-based  Ada  compiler  implementations. 

•  Ada  Limited  Debugging  Assistance.  BBS  usm  can  upload  small  amounts  of  code 
to  be  dd)ugged.  The  submitted  code  must  be  limited  to  a  few  inogtam  units. 
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•  AdaSAGE  Question  end  Answer  Service.  Many  DOS-Ada  i^licaticm  developen 
use  AdaSAGE  for  Database  Managemmt  System  (DBMS)  functions.  This  service 
is  for  AdaSAGE  users.  Users  will  be  able  to  ask  one  another  questions  about 
AdaSAGE. 

•  AdaSAGE  Conumnt  Sendee.  BBS  users  can  comment  on  Ada  aqsplication 
devdopment  using  AdaSAGE.  Comments  can  either  rq)ort  problmns  with 
AdaSAGE  or  suggest  enhancements  that  would  benefit  future  versions  of 
AdaSAGE.  These  comments  will  be  collected  and  presented  periodically  at 
AdaSAGE  enhancement  meetings.  Users  may  also  request  AdaSAGE 
enhancements. 

•  Ada  Example  Set.  This  collection  of  code  shows  Ada  features.  BBS  users  can 
download  the  code,  study  it,  and  ask  questions  about  it.  Users  also  can  upload 
code  that  shows  Ada  features. 

•  News.  The  BBS  will  list  Ada  news,  events,  and  interesting  Ada  products  and  their 
points  of  contact. 

The  service  is  free  and  available  to  the  public.  However,  the  limited  drugging  service 
is  available  to  bona  fide  Government  employees  and  their  contractors. 

STSC  Bulletin  Board  System 

Ogden  Air  Logistics  Center 

USE 

HillAFB,UT  840S6 

(801)  774-6509 

DDN:  Telnet  137.241.33.1  or  stscbbs.oo.aflc.af.mil 

The  STSC  sponsors  the  Electronic  Customer  Services  (ECS),  which  is  divided  into  the 
Bulletin  Board  System  (BBS)  and  the  Central  Database  (CDB).  The  purpose  of  ECS  is 
to  present  the  latest  software  information  and  knowledge  to  software  practitioners  in  the 
DOD,  industry,  and  academia. 

To  access  the  ECS  by  modem,  use  the  following  settings: 

•  Baud  rate  =  300,  1200,  24(X),  or  9600 

•  Parity  =  none 

•  Data  bits  =  8 

•  Stop  bits  =  1 
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The  BBS  offers  information  and  news  on  a  variety  of  software  topics.  The  entries  on  die 
main  menu  are  as  fcdlows: 

•  Ada  Irfft>nnation.  Presents  the  most  recent  Ada  informatiai,  policy,  news  and 
trends. 

•  VSAF  Software  Policy  and  Regulations.  Abstracts  aqiplicable  software  policies  and 
r^ulations  including  POC  or  author,  office  of  responsibility,  address,  phone 
nunriier,  and  latest  date  of  publicadcxi. 

•  Notes.  Allows  users  to  leave  a  note,  make  a  comment,  or  present  their  views  to 
the  STSC  and  other  BBS  customers  on  any  software  subject.  The  STSC  will  then 
put  the  notes  into  the  appropriate  BBS  domain  for  subsequent  viewing  and 
comnmnt. 

•  Crosstalk,  The  Journal  of  Defense  Software  Engineering.  Lists  every  issue  of  the 
STSC*s  journal  of  software  engineering.  Hard  copies  are  available  on  request. 

•  DOD  Corporate  Irformation  Management  (CIM).  Presents  most  recent 
inftmnaticm  from  high-level  DOD  software  management. 

•  Irfttrmation  Technology  Policy  Board  (ITPB).  Presents  most  recent  information 
on  and  activities  of  this  CIM-sponsored  board. 

•  Corferences,  Meetings,  Semiruirs.  Contains  a  comprdiensive  calendar  of  software 
activities  sponsored  by  the  Government,  industry,  academia,  and  intematitmal 
agencies. 

•  (Mier  &dletin  Board  Systems.  Lists  BBSs  sprmsored  by  the  Government,  industry, 
and  academia. 

•  Other  Software  Orgaruzations.  Lists  software  organizations  sponsored  by  the 
Govonment,  industry,  and  academia. 

•  Software  Tedmical  Damcdns.  Contains  domains  such  as  system  simulatim, 
requirements  tracing,  design,  coding,  testing  and  int^ration,  documentation, 
project  management,  configuration  management,  quality,  metrics,  environments, 
and  databases. 

•  Software  Engineering  Topics.  Includes  education,  goals,  and  logistics  (softlog), 
m^ods,  metrics,  processes,  quality  reengineering,  and  reuse. 
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•  St^tware  News.  Gives  access  to  an  electronic  newsps^  featuring  news  and 
information  from  the  software  community. 

•  Software  Periodicals  and  Books.  Pr^ents  a  list  of  the  software  periodicals, 
newiQM^iers,  journals,  magazines,  and  newsletters  published  by  the  Government, 
indu^,  and  academia. 

•  Software  Tedmology  Cortference.  Presents  news  about  the  annual  Software 
Technolt^y  Conference  (STC)  held  each  April  in  Salt  Lake  City,  Utah. 

•  STSC  Documents.  Lists  all  of  the  documents  and  rqiorts  generated  or  qxmsoied 
by  the  STSC.  Hard  copies  will  be  sent  on  request. 

•  White  Papers.  Contains  technical  proposals  from  the  software  community  at  large. 

•  Upload  Files  to  the  STSC.  Contains  instructions  on  how  to  upload  files  to  the 
STSC. 

The  CDB  is  a  repository  of  software  tool  information.  It  gives  descriptions  of  tools, 
addresses  of  vendors,  and  the  ability  to  query  for  selected  tool  domains. 

Cost  Bulletin  Board  System 
Air  Force  Cost  Center 
nil  Jefferson  Davis  Highway,  Suite  403 
Arlington,  VA  22202 
(703)  746-5840 
DSN:  286-5840 

Air  Force  Cost  Bulletin  Board  PCK!:  Ray  Scheuring 

(703)  746-5875  or  5876 

1-800-344-3602 

The  Cost  BBS  provides  an  automated  means  of  exchanging  information,  and  uploading 
and  downloading  cost  models  and  factors.  If  you  have  modds  or  information  you  would 
like  to  have  included,  contact  the  system  operator  or  leave  a  message  on  the  bulletin 
board. 

To  access  the  Cost  BBS,  you  must  have  an  IBM-compatible  microcomputer, 
communications  software  that  allows  XMODEM  (checksum),  XMODEM  (CRC),  ASCII, 
YMODEM  or  KERMIT  file  transfer  proU)cols,  and  a  Hayes-compatible  modem. 
Communications  settings  are  as  follows: 
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•  Baud  rate  «  1200  or  2400 

•  Parity  »  none 

•  Data  bits  «  8 

•  Stop  bits  »  1 

Nattonal  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield.  VA  22161 
(703)  321-8020 

The  NTIS  Bulletin  Board  provides  information  on  Computer-aided  Acquisition  and 
Logistics  Support  (CALS),  CIM  (e.g..  Technical  Reference  Model),  and  more. 
Crmimunications  settings  are  as  follows: 

•  Baud  rate  »  1200  or  2400 

•  Parity  “  nmie 

•  Data  bits  «  8 

•  Stop  bits  »  1 

A.l^  Rqrasitoiles 

Ada  Software  Repo^ory 

ada-sw-request®wsmr-simtel20.army.mil 

The  Ada  Software  Repository  (ASR)  contains  Ada  programs,  software  components,  and 
educational  material  that  has  been  established  tm  the  Defense  Data  Networic  (DDN). 
This  rqx)sitory  has  been  accessible  to  any  host  computer  on  die  DDN  since  26 
Novem^  1984. 

ASR  is  a  ftee  source  of  Ada  programs  and  informadon.  By  employing  the  File  Transfer 
Protocol  (f^)  program,  users  of  DDN  hosts  are  able  to  scan  the  directories  of  the 
rqmsitory  and  transfer  files  to  their  hosts.  If  the  files  are  Ada  programs,  th^  may  then 
ocMDopile  diese  programs  and  use  them  as  they  desire.  Modifying  diese  programs  may  be 
widiin  their  rights,  and  th^  may  freely  distribute  these  programs  as  they  wish,  subject 
to  die  restrictions  specified  in  the  prologue  of  each  inece  of  software. 

All  members  of  the  Ada  community  are  encouraged  to  extract  informatimi  and  programs 
fnmi  die  repository  and  to  make  contributions  to  it  The  rnily  restricticms  that  apply  to 
access  and  use  of  diis  software  are  presented  in  the  Distribution  and  Copyright  section 
of  the  prologue  associated  with  each  piece  of  software. 
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ASR  is  one  of  several  repositories  located  on  the  SIMTEL20  DDN  host  computer  at 
White  Sands  Missile  Range.  New  Mexico.  S1MTEL20  is  owned  and  operated  by  the 
Operations  and  Systems  Integration  Division  of  the  Information  Systems  Command  of 
the  U.S.  Army. 

ASR  maintains  source  code  from  approximately  10,000  Ada  programs.  These  programs 
are  maintained  by  the  domains  of  Artificial  Intelligence  (AI),  Benchmarks, 
Reusable  Software  Components,  Documentation,  Gr^ihics,  Project 
Management.  Ada  Software  Development  Tools,  and  many  others.  The  ASR  is  available 
ftuough  f^  and  on  magnetic  ta^,  ftoppy  disk,  and  CD-ROM. 

An  introduction  to  the  ASR  can  be  obtained  by  using  the  following  commands  on  a 
system  that  supports  ftp  on  the  DDN: 

>f^  wsmr-simtel20.army.mil 

when  asked  for  login  name,  type  in  anonymous 

when  asked  for  password,  type  in  your  user-id 

f|p>ls  —provides  listing  of  login  directory 

f^>get  SIMTEL20-ADA.INF  —copies  file  to  your  local  directory 

frp>quit  —returns  control  to  UNIX 

Tape  copies  are  available  from: 

The  DECUS  Program  Library 
219  Boston  Post  Road  BP02 
Marlboro,  MA  01752 
(508)  480-3418 

MS-DOS  high-density  diskette  copies  are  available  from: 

Advanced  Software  Technology,  Inc. 

P.O.  Box  937 
Medford,  NY  11763 
(516)  289-6646 

CD-ROM  copies  are  available  from: 

ALDE  Publishing 
P.O.  Box  35326 
4830  West  77th  Street 
Minneapolis,  MN  55435 
(612)  835-5240 
FAX:  (612)835-3401 
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An  electronic  mailing  list  exists  on  SINrrEL20  for  those  who  are  interested  in  accessing 
and  contributing  software  to  the  ASR.  To  subscribe  to  this  mailing  list,  seiul  a  request 
to  the  electronic  mail  address  above. 

Air  Force  Defense  Software  Repository  Systran 
SSC7SSB  Building  856,  Room  265 
Maxwell  AFB,  Gunter  Annex,  AL  36114-5000 
(205)  416-5857 
DSN:  596-5857 
FAX:  (205)416-5964 

The  Air  Force  Defense  Software  Rq)ository  System  (AFDSRS)  is  a  repositoiy  of  Air 
Force  and  commorcial  reusable  software  assets,  including  functional  requirements,  design 
q)ecifications,  architectures,  design  diagrams,  source  code,  documentation,  and  test 
suites.  AFDSRS  is  accessible  by  modem  or  the  DDK  and  is  linked  to  the  Defense 
Information  Systems  Agency  (DISA)  Center  for  Software  Reuse  Operations  (CSRO) 
library,  which  offers  access  to  all  DOD  components. 

Associate  Director,  MCSD 

AMSEL-RD-SE-BCS-MC  (C2MUG) 

Fort  Leavenworth,  KS  66027 
AUTOVON:  552-7550 
FTS:  753-7550 
(913)  684-7550 

The  C2MUG  Software  Catalog  for  mathematics  and  various  Ada  functions  is  available 
to  all  echelons  of  the  U.S.  military  and  elements  of  the  Federal  Government.  Software 
components  are  primarily  for  microcomputers. 

Central  Archive  for  Reusable  Defense  Software  Program 
CARDS 

1401  Country  Club  Road,  Suite  201 
Fairmont,  WV  26554 
(304)  363-1731 

CARDS  Hotline:  1-800-828-8161  or  (304)  367-0421 
E-mail  for  Hotline:  hotline@cards.com  (Internet) 

Cards  Program  Sponsor:  ESC/AVS,  Hanscom  AFB,  (617)  377-9369 
DSN  478-9369 

The  Central  Archive  for  Reusable  Defense  Software  (CARDS)  program  is  a  concerted 
DOD  effort  to  move  advances  in  the  techniques  and  technology  of  architecture-centmed, 
domain-specific  software  reuse  into  mainstream  DOD  software  procurements.  CARDS 
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is  sq;)plying  the  latest  technology  to  provide  an  implementation  rramework  for  reuse 
libraries  in  domains  of  interest  to  the  DOD.  CARDS  is  currently  applying  the 
hnamework  to  a  Command  Center  Domain  Library.  CARDS  is  working  closely  with  the 
Portable  Reusable  Integrated  Software  Modules  (PRISM)  program,  which  is  integrating 
Commercial-Off-The-Shelf  (COTS)  and  Govemment-Off-The-Shelf  (GOTS)  products  to 
perform  80%  of  the  general  functions  of  normal  command  center  operations.  The 
CARDS  program  is  currently  developing  several  reuse  handbooks. 

Cmninand,  Control,  Communications,  and  Intelligence  Reusable  Software  System 
Mr.  Ron  Crepeau 
NRaD 

271  Catalina  Boulevard 
San  Diego,  CA  92152-5000 
(619)  553-3990 
crq)eau@nosc.mil 

The  Command,  Control,  Communications,  and  Intelligence  Reusable  Software  System 
(CRSS)  is  a  repository  of  Navy  Command  and  Control  (C2)  assets,  including  source  and 
executable  code,  documentation,  and  graphical  representations.  The  library  has  been 
devdoped  under  the  Operations  Support  System  (OSS)  project  to  promote  rapid 
prototyping  of  C2  systems.  Replication  of  the  CRSS  is  available  on  magnetic  media  or 
by  modem. 

Common  Ada  Missile  Components  Effort 
Data  and  Analysis  Center  for  Software 
do  Kaman  Sciences  Corporation 
P.O.  Box  120 
Utica,  NY  13503 
(315)  336-0937 

Common  Ada  Missile  Packages  (CAMP)  are  operational  flight  software  parts  written  in 
Ada  for  tactical  missiles.  CAMP  consist  of  454  reusable  Ada  components.  The  software 
is  distributed  on  ANSI  standard  labeled  9-track  16(X)-bits-per-inch  tapes.  Additionally, 
videobqpes  on  Ada  reuse  are  available,  such  as  "Common  Ada  Missile 
Packages— Leading  the  Way  in  Software  Reuse.”  This  videotape  provides  an  overview 
of  Ada,  software  reuse,  and  the  CAMP  program. 
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Data  and  Analysis  Center  for  Software 
258  Genesee  Street 
Suite  101 
Utica,  NY  13S02 
(315)  734-3664 

Although  ntrt  an  interactive  iqx)sitoiy,  Data  and  Analysis  Center  for  Software  (DACS) 
provides  several  products  and  services.  Of  importance  are  the  following:  the  Ada 
Conquer  Evaluation  System  (ACES),  (a  set  of  Ada  benchmarks),  CAMP  (a  collection 
of  reusable  Ada  packages),  a  set  of  benchmarks,  and  a  cataloging  focility  in  addition  to 
various  technical  reports. 

Defense  Software  Repository  System 
DISA/JIEO/CIM  Software  Reuse  Program 
500  North  Washington  Street,  Second  Floor 
FaUs  Church,  VA  22046 
(703)  536-6900/7485 

The  DISA  Joint  Interoperability  and  Engineering  Organization  (JIEO)  aird  CIM  Software 
Reuse  Program  (SRP)  is  an  element  of  the  DOD  Software  Reuse  Initiative  under 
DISA/JIEO/CIM.  The  DISA/JIEO/CIM  mission  is  to  provide  software  raise  products 
and  reusable  software,  training,  and  access  to  the  Defense  Software  Rqxisitory  System 
(DSRS).  The  SRP  includes  support  of  DOD  Software  Reuse  Centers  at  the  Service  and 
agency  levels  throughout  DOD  to  coordinate  software  reuse  efforts  and  maximize  cross¬ 
domain  sharing. 

National  Aeronautics  and  Space  Adniinistration*s  AdaNet 
AdaNet 

do  MountainNet 
Ea.stgate  Plaza,  2nd  Floor 
P.O.  Box  370 
Dellslow,WV  26531-0370 
(304)  296-1458 
1-800-444-1458 

AdaNet’s  primary  purpose  is  to  increase  U.S.  productivity,  economic  growth,  and 
competitivaiess  through  development  of  a  life-cycle  repository  for  software  engineering 
products,  processes,  interfaces,  and  related  information  services.  AdaNet  is  sponsored 
by  NASA,  and  there  is  no  charge  for  an  account. 

AdaNet  provides  the  following  information  and  services: 
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•  Access  to  Ada  source  code  libraries 

•  Bibliographic  references  to  Ada  and  software  engineering  publications 

•  Descriptions  of  public  and  commercial  rq)ositories  of  Ada  software 

•  Directories  of  Ada  and  software  engineering  commercial  products 

•  Electronic  forums  on  topics  such  as  software  reuse  and  CALS 

•  Listings  of  international  Ada  professional  organizations 

•  Monthly  listings  of  relevant  conferences  and  seminars 

•  References  to  public  and  private  Ada  information  services. 

Navy  Wide  Reuse  Center 

Project  Manager,  Navy  Wide  Reuse  Center 

Wa^ngton  Navy  Yard 

Building  196 

Code  NS3,  Room  4508 

Washington,  D.C.  20374 

POC:  Angus  Faust 

(202)  433-0718 

nhis.navy.mil 

The  Navy  Wide  Reuse  Center  (NWRC),  which  was  dedicated  on  16  March  1992,  will 
provide  a  comprehensive  reuse  support  environment  for  all  Navy  domains.  The  center 
will  ser\'e  as  a  repository  for  all  Navy  reusable  components  and  provide  interfaces  to 
other  DOD  and  non-DOD  repositories  as  well  as  information  on  commercially  available 
reusable  components.  NWRC  uses  the  DSRS  hosted  on  a  DEC  MicroVAX  computer. 
DSRS  is  accessible  through  DDN,  modem  dial-up,  and  selected  Local  Area  Networks 
(LANs).  An  account  on  the  system  is  required  and  should  be  requested  through  the 
above  address. 

Reusable  Ada  Products  for  Information  Systems  Development 
U.S.  Army 
Army  Reuse  Center 
Fort  Belvoir,  VA  22060-5456 
Attn.:  USAISEC  Stop-HlO 
(703)  285-9007 
DSN:  356-9007 

The  Reusable  Ada  Products  for  Information  Systems  Development  (RAPID)  Program  is 
a  total  Ada  software  reuse  program  established  at  the  U.S.  Army  Information  System 
Software  Center  (ISSC)  Software  Development  Center,  Washington  (SDC-W).  This 
program  has  become  the  basis  for  the  DSRS  under  the  DISA  CIM.  Under  this  system, 
a  repository  has  been  established  for  each  Service.  The  NWRC  serves  as  the  repository 
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for  all  Navy  reusable  components  and  provides  an  interfiace  to  the  central  rqKmtory  and 
other  service  repositories  under  the  DSRS. 

Software  Technolosy  for  Adaptable,  Reliable  Systons  Repodtory 
blanchard®staTs.startech.com 

STARS  maintains  a  rqmntory  of  Ada  binding  to  Motif,  Ada  binding  to  Ada/Xt  Windows 
Intrindnts,  Reuse  Library  Framework  (RLF),  and  many  more. 

Tape  copies  are  available  from: 

Asset  Source  for  Software  Engineering  Technology  (ASSET) 

2611  Cranberry  Square 
Bldg.  2600,  Suite  2 
Morgantown,  WV  26S0S 
(304)  594-1762 

MS-DOS  high-density  diskette  copies  are  available  from: 

Advanced  Software  Technology,  Inc. 

P.O.  Box  937 
Medford,  NY  11763 
(516)  758-6545 

A.1.6  Conferences  and  Special  Interest  Grmips 

ASEET  Symposium 

Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria,  VA  22311 
(703)  825-6626 

The  ASEET  Team  Coordinator  Working  Group  (CWG)  sponsors  the  aimual  ASEET 
Symposium.  The  symposium  enables  DOD  personnel  to  learn  about  new  education  and 
training  methods  from  industry,  academia,  and  DOD  organizations. 

DON  Ada  Users  Group 

DON  Ada  Users  Group-Chair 
Naval  Ocean  Systems  Center 
271  Catalina  Boulevard 
San  Diego,  CA  92152-5000 
(619)  553-2303 
FAX:  (619)553-5799 
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The  DON  Ada  Users  Group  has  been  chartered  to  provide  information  and  suj^rt  to  the 
DON  on  use  of  the  Ada  programming  language  and  Ada-related  issues  associated  with 
software  development  and  maintenance.  Regular  meetings  are  held  in  ccmjunction  with 
national  conferences  in  the  Ada  community,  such  as  those  sponsored  by  Tri-Ada  and 
SIGAda. 

STARS  Workshop 
IDA/CSED 
Sill  Leesburg  Pike 
Falls  Church.  VA  22041 
(703)  845-3520 

The  STARS  Joint  Program  Office  holds  workshops  to  publicize  and  disseminate 
information  on  various  contract  efforts. 

Software  Technology  Conference 
Software  Technology  Support  Center 
Ogden  ALC/nSE 
HillAFB,  UT  84056 
(801)  777-7703 

The  annual  STC  is  held  each  April  in  Salt  Lake  City,  Utah.  This  conference,  ^nsored 
by  the  STSC  and  the  Headquarters  of  each  Service,  is  a  forum  for  sharing  technology 
solutions  and  bringing  together  the  DOD  Government  and  contractor  software  community 
to  otchange  ideas  and  information. 

A.1.7  Operational  Development  Support  Tools 

Ada  Language  System/Navy 

Naval  Sea  Systems  Command  (PMS-412) 

NC-3 

2531  Jefferson  Davis  Highway 
Washington,  D.C.  20362-5101 
(703)  602-8204 

The  ALS/N  is  a  software  development  environment  and  Run-Time  Environment  (RTE) 
system  that  is  being  developed  for  the  current  generation  of  DON  standard  computers, 
the  AN/UYK-43(V),  AN/UYK-44(V),  and  AN/AYK-14(V).  ALS/N  has  a  users’  group 
and  a  bulletin  board  available  upon  request  and  target-based  training  available  through 
the  project  office. 
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AdaSAGE 

Department  of  Energy 

Uabo  Naticmal  Engineering  Laboratory  (INEL) 

Idaho  Falls,  ID 
(208)  326^)656 
Internet:  jij®mica.inel.gov 

AdaSAGE  is  a  Government-owned  developmmt  reuse  tool  utilized  by  all  DOD 
components.  The  tool  consists  of  utilities  that  support  user-develcqped  interfaces,  reports, 
and  data  and  their  relationships.  These  utilities  facilitate  user-directed  prototyping. 
AdaSAGE  is  free  and  is  supported  by  a  Joint  Service  Configuration  Management  Board. 
Enhancements  may  be  requested  by  leaving  a  message  on  the  Ada  Technical  Support 
Bulletin  Board  listed  in  A.1.4. 

NAVAIR  Software  Engineering  Environment  Tool  Set 
Charles  Koch 
Code  7033 

Naval  Air  Development  Center  (NADC) 

Warminster,  PA  18974-SOOO 
(215)  441-2752 

The  Naval  Air  Systems  Command  (NAVAIR)  Software  Enginearing  Environment 
(NASEE)  Working  Group  contracted  for  12  software  tools  for  use  throughout  the 
software  life  cycle.  NAVAIR  has  made  these  tools  a  standard  for  its  Software  Siqrport 
Activities  (SSAs).  The  NADC  provides  information  on  the  NASEE  Working  Groiq>  and 
on  ways  to  obtain  these  tools. 

Tool  Box  PC 

Software  Technology  Support  Center 
Hill  AFB,  UT  84056 
1-800-477-2449 

This  tool,  written  in  Ada,  is  an  interactive  catalog  application  tool  that  has  Ada  and  oUict 
Government-  and  commercially  owned  software  languages.  This  system  is  designed  for 
managers’  use.  The  program  is  available  free  to  the  public  on  5V4-  and  3*A-inch  disks. 
The  Air  Force  supports  this  program  through  the  STSC. 
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AJ  Ada  INFORMATION  CLEARINGHOUSE 

The  latest  information  about  Ada  is  available  free  of  charge  from  the  AJPO’s  AdalC. 
The  AdalC  makes  available  information  on  a  variety  of  topics  ranging  from  the  use  of 
Ada  within  DOD  and  industry  to  tools  and  compilers  for  Ada  developers,  and  from  DOD 
policies  r^arding  Ada  to  reusable  Ada  software. 

The  AJPO  sponsors  the  AdalC.  The  AJPO  is  responsible  for  informing  the  community 
about  Ada,  facilitating  the  language's  implementation  in  the  services,  and  maintaining  the 
int^ty  of  the  language. 

The  telephone  hot  line  numbers  are  1-800- ADA-IC 1 1  (232-42 1 1)  or  (703)  685- 1477.  For 
answers  to  your  Ada  questions,  call  the  AdalC,  Monday  through  Friday,  from  8:00  a.m. 
to  5:00  p.m..  Eastern  Time. 

Informational  Flyers 

More  than  1(X)  different  informational  flyers  or  reports  are  available  from  the  AdalC. 
Flyer  topics  include: 

•  Ada  Validated  Compilers 

•  Ada  News  and  Current  Events 

•  Ada  Usage 

•  AJPO’s  Ada  Technology  Insertion  Program  (ATIP) 

•  Ada  9X  project 

•  On-line  sources  of  Ada  information 

•  Ada  bibliographies 

•  Ada  Compiler  Validation  and  Evaluation 

•  Resources  for  Ada  Education  and  Training 

•  Ada  Software,  Tools,  and  Interfaces 

•  Ada  Regulations,  Policies,  and  Mandates 

•  Ada  Historical  Information 

•  Standards  and  Available  Ada  Bindings  Products. 

These  flyers  are  available  electronically  on  two  AJPO-sponsored  computer  systems:  the 
AJPO  host  computer  on  the  Internet,  and  the  AdalC  Bulletin  Board  P^)er  copies  of  the 
flyers  are  provided  upon  request. 

The  Validated  Compilers  List  is  one  of  the  most  frequently  requested  flyers.  This  list, 
which  is  updated  monthly,  contains  information  on  all  compilers  that  have  currently 
active  validation  certiflcates. 
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On-Line  Infonnation 

Most  AdalC  flyers  and  other  publications  are  available  on-line  (Hi  the  AJPO  host 
cominiter  and  on  the  AdalC  Bulletin  Board.  These  electronic  sources  also  have  other 
files,  such  as  those  whose  length  or  complexity  preclude  easy  distribution  in  paper-copy 
form.  In  addition,  the  AJPO  provides  information  related  to  the  Ada  9X  project  on  a 
dedicated  bulletin  board  and  on  the  AJPO  host. 


The  AJPO  Host  on  the  Internet 

For  those  with  access  to  the  Internet,  AJPO  makes  a  variety  of  Ada  informaticm  available 
on  the  AJPO  host  computer  on  the  Internet.  Its  name  is  ajpo.sei.cmu.edu. 

The  AJPO  host  can  be  accessed  by  the  File  Transfer  Program  (FTP),  which  allows  a  user 
to  transfer  files  to  and  from  a  remote  network  host  site.  FTP  should  work  for  any  host 
on  the  Internet. 


A  sample  FTP  connection  follows, 
[your-prompt]  ftp  ajpo.sei.cmu.edu 
name:  anonymous 
password:  guest 
f^>  cd  public 
f^>  dir 

f^>  cd  [sub-directory] 
fi^>  dir 

f^>  get  fllel.hlp  [newname.hlp] 
f^>  mget  filel  ...  flleN 
f^>  bye 


execute  ftp  from  your  remote  site 

login  using  "anonymous” 

enter  password  of  "guest* 

change  to  the  "public"  subdirectory 

view  a  list  of  accessible  subdirectories 

change  to  the  subdirectory  of  your 
choice 

view  a  list  of  available  files 

get  "filel.hlp”  from  f^  and  copy  it  to 
"newname.hlp”  on  your  machine 

get  multiple  files  from  f^  and  load  them 
onto  your  machine  with  the  same  names 

logout  when  finished 


For  more  information  on  the  AJPO  host,  type  "get  README"  and  "get  README.FTP" 
after  an  f^  connection  is  made. 

For  those  without  Internet  access,  the  AdalC  Bulletin  Board  is  available  (Hi  a  24-hour 
dial-up  basis. 
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AdalC  Bulletin  Board 

Cmnmercial:  (703)  614-02 IS 

AUTOVON:  224-0215 

The  AdalC  Bulletin  Board  contains  most  of  the  infwmation  provided  on  the  AJPO  host 
otmtputer-- plus  on-line  databases. 

The  bulletin  board  can  be  accessed  by  dialing  one  of  the  numbers  listed  above.  Users 
should  stt  their  telecommunications  package  with  the  following  parameten: 

•  Baud  rate  »  300  through  9600  baud 

•  Data  bits  »  8 

•  Parity  »  none 

•  Stop  bits  »  1. 

The  first  time  you  log  on,  you  will  be  prom}^  to  raster  for  an  account. 

The  [D]oors  feature  of  this  bulletin  board  provides  users  with  the  capability  to  search  six 
AdalC  databases: 

•  The  Validated  Ada  Compilers  (VCL)  P>]oor  provides  full  text  seardiing  of  the 
Validated  Compiler  list  by  host  and  by  target  >i^iere  different  from  host. 

•  The  Ada  Programming  Tools  (TOOLS)  (D]oor  contains  information  about  more 
than  200  Ada  vendors,  their  more  than  300  Ada  products,  and  die  hardware  on 
udiich  they  run. 

•  The  Current  Ada  Articles  (NEWS)  [D]oor  provides  full  text  searching  of  AdalC's 
abstracts  of  Ada-related  articles  diat  haw  been  published  in  trade  and  technical 
journals. 

•  The  Ada  Bibliography  (BIBS)  [D]oor  provides  users  with  a  comprdiensive 
bibliogn^hy  of  Ada-r^ttxl  publicadcms. 

•  The  Bibliography/ Abstracts  (ABS-BIB)  (Djoor  provides  users  with  a  bibliogrqihy 
of  Ada-related  documents  as  well  as  an  abstract  for  each  bibliogrqihic  citation. 

•  The  Ada  Education  (CREASE)  [Djoor  provides  access  to  the  AdaIC*s  "Catalog  of 
Resources  for  Education  in  Ada  and  Software  Engineering,"  Version  6.0,  1992. 
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The  Ada9X  Prop’s  electionic  bulletin  board  is  a  comprehensive,  one-stop  source  of 
inibnnation  oonoeming  the  Ada9X  inoject.  All  of  the  revision  requests  dud  were 
submitted  to  the  inogect  are  available  for  viewing  and/or  downloading  from  die  bulletin 
board.  In  addition,  most  of  the  prqject  rqiorts  and  all  of  the  Ada9X  pngect 
announcements  are  available. 

The  Ada9X  Bulletin  Board  can  be  accessed  by  dialing  one  of  die  numbers  listed  above. 
Usen  should  set  their  telecommunications  package  widi  the  following  parameters: 

•  Baud  rate  «  300  through  2400 

•  Data  bits  8 

•  Parity  *  none 

•  Stop  bits  s  1 

Databases 

In  addition  to  die  database  available  for  searching  on  the  AdalC  Bulletin  Board,  die 
AdalC  also  maintains  a  database  of  Ada  projects.  Tlie  Ada  Usage  database  was 
developed  to  track  how  Government,  education,  and  industry  are  using  Ada  in  software 
devdo^nent  efforts.  Currently,  there  are  more  than  650  efforts  described  in  the 
database. 

Ada  Usage  informatitm  can  be  obtained  only  with  the  voluntary  cooperation  of  the 
prcgect  If  you  are  currently  involved  in  an  Ada  development  project  or  if  you  have 
conqileted  a  project  using  A^,  we  would  like  to  add  your  information  to  our  database. 

Written  Inquiries 

If  you  prefer  to  send  a  written  inquiry  or  would  like  to  share  any  Ada-related  information 
witii  us,  send  mail  to: 

Adalnformation  Clearinghouse 
P.O.  Box  46593 
Washington,  D.C.  20050-6593 

A  Jt.l  Public  Access  to  the  AdalC  Bulletin  Board  (ada-rbbs.hlp  extract) 

The  AdalC  Bulletin  Board  is  a  publicly  available  source  of  information  cm  the  Ada 
language  and  Ada  activities.  Sponsored  by  the  AJPO  and  maintained  by  AdalC,  this 
bulletin  board  is  used  to  announce  current  events  and  general  activities  and  provide  a 
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cur^nt  listing  of  validated  Ada  compilers.  Access  to  the  ouUetin  board  requires  a 
computer  terminal  and  modem  or  a  PC  and  modem. 

The  AdalC  Bulletin  Board  system  can  be  accessed  by  dialing  (703)  614-0215  or  (301) 
4S9-386S.  Users  should  set  their  telecommunications  pacl^e  with  the  following 
parameters: 

•  Baud  rate  »  300,  1200,  or  2400 

•  Parity  »  none 

•  Data  bits  «  8 

•  Stop  bits  »  1 

Currently,  the  following  12  directories  are  available: 

•  The  Ada  Information  Directory— an  alphab^cal  listing  of  all  available  information 
files,  with  a  contents  description  for  each  one 

•  The  Language  Reference  Manual  Directory— the  Ada  Language  Reference  Manual 
(ANSI/MIL-STD-181SA-1983)  in  its  entirety 

•  The  Approved  Ada  Commentaries  Directory— q>proved  commentaries  resqxmding 
to  questions,  pr(4>lems,  and/or  inconsistencies  and  perceived  inconsistoicies 
rq^arding  the  Ada  Language  Reference  Manual  (ANSI/MIL-STD-181SA-1983) 

•  The  Ada  Language  Rationale  Directory— the  rationale  for  the  design  of  the  Ada 
Programming  Language  in  its  entirety 

•  The  CAIS  Document  Directory— CAIS  documents  (October  1986) 

•  The  AdalC  Newsletter  Directory— past  AdalC  newsletters 

•  The  CREASE  Directory— AJPO’S  Catalog  of  Resources  for  Education  in  Ada  and 
Software  Engineering,  Version  5.0,  in  its  entirety 

•  The  Miscellaneous  Directory— files  such  as  those  used  to  decompress  compressed 
files 

•  Directories  9  and  10— a  guiddxmk  and  reference  manual,  respectively,  for  the 
evaluation  and  validation  of  Ada  programming  support  environments 
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•  Directory  ll^the  NASA-Goddard  Ada  Style  Guide,  which  was  proposed  as  the 
basis  for  a  military  handbook 

•  Directory  12— a  csdalc^  of  the  ASR  and  the  ASR  User’s  Handbook. 

Files  are  available  in  either  compressed  or  uncompressed  (ordinary  ASCII  text  file) 
format  Most  are  available  in  both. 

kJlJl  Access  to  Ada  Infonnation  oa  the  Detease  Data  Network  (ada-ddn.hlp  extract) 
The  public  directory  on  the  ajpo  host  computer  is  an  official  source  of  information  rni 
the  Ada  language  and  Ada  activities.  Sponsored  by  AJPO  and  maintained  by  AdalC,  this 
computer  directory  is  used  to  announce  current  events  and  general  activities  and  to 
provide  a  current  listing  of  validated  Ada  compilers. 

This  directory  is  available  only  to  authorized  users  of  the  DDN.  However,  AdalC  also 
nuuntains  a  bulletin  board  at  (703)  614-021S  and  (301)  459-3865.  For  information,  see 
the  AdalC  handout,  "Public  Access  to  the  Ada  Information  Bulletin  Board"  (AdalC  from 
GA^51,  ffle  ADA-RBBS.HLP). 

The  DDN  is  a  collection  of  approximately  80  different  computer  networks  rqnesenting 
DOD  facilities,  research  centers,  and  academic  institutions  throughout  the  free  world. 
All  of  the  networks  are  packet-switching  systems  with  interconnections  at  various 
locations.  DOD  controls  access  to  the  DDN.  To  obtain  access  to  the  DDN,  it  is  first 
necessary  to  have  an  account  or  access  to  an  account  on  one  of  the  several  thousand  host 
computers  that  make  up  the  system. 

The  following  set  of  commands  provides  an  example  of  the  use  of  ftp  to  transfer  a  file 
from  the  ajpo  host  to  a  local  host.  The  file  is  in  the  directory 
public/ada-info/val-comp.hlp. 

>f^  ajpo.sei.cmu.edu 

when  adeed  for  login  name,  type  in  anonymous 

when  asked  for  password,  type  in  your  user  id 

fi9>  >  Is  —provides  listing  of  login  directory 

f^>  cd  public  —changes  directory  to  the  public  directory 

fi5»  cd  ada-info  —changes  directory  to  the  ada-info  directory 

flp>  get  val-comp.hlp  —copies  file  to  your  local  directory 

ffo>  quit  —returns  control  to  UNIX 

As  of  17  March  1992,  directories  in  the  public  directory  include  acvc-current, 
ada-adoption-hbk,  ada-comment,  ada-info,  ada-lm,  ada-ui,  ada9x,  adanews,  adastyle, 
artdata,  asis,  cais,  crease50,  ev-info,  infoada,  Idtdata,  Irm,  pds,  piwg,  rationale,  and 
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wbs.sw.  These  files  correspond  to  those  shown  in  Table  A-1.  This  appendix  provides 
die  primary  Ada  information  files  in  the  AdalC  File  Directory. 

A.2J  Iiifo_Ada  Digest 

DDN  users  can  also  access  the  Info_Ada  Digest  (to  send  discussions  to  the  digest,  use 
info_ada®igpo.sei.cmu.edu).  To  request  that  you  be  added  to  the  discussiem  list,  use 
info_ada_requests®ajpo.sei.cmu.edu.  Alternatively,  the  same  discussions  are  available 
diroiigh  USENEWS  news  group  comp.lang.ada. 

DDN  users  can  also  access  the  Ada_Ed  Digest.  To  send  discussiems,  use  ada- 
ed®east.pima.edu.  To  request  that  you  be  added  to  the  discussion  list,  use  ada-ed- 
requests®east.pima.edu. 

The  Ada  electronic  mailing  list  includes  the  following: 

•  Ada  announcements 

•  Open  forum  for  discussion 

•  C^ien  forum  for  questions 

•  R^uests  for  information  to  the  entire  Ada  community. 

A.2.4  Document  Reference  Sources 

In  addition  to  the  information  available  from  AdalC,  many  documents  are  available  fiom 
sources  described  below.  This  information  is  taken  from  the  AdalC  Document  Reference 
List. 

Govamnent  Printing  Office 
Superintendent  of  Documents 
Government  Printing  Office 
Washington,  D.C.  20402 
(202)  783-3238 

The  Government  Printing  Office  (GPO)  distributes  the  Reference  Manual  for  the  Ada 
Programming  Language  to  the  general  public  and  industry  for  $16  a  copy.  Mail  orders 
may  be  sent  to  the  above  address  with  payment  included.  Telephone  orders  are  accqpted 
with  a  VISA  or  Master  Card  number  or  a  GPO  deposit  account  number.  For  additional 
information,  call  the  number  noted  above. 

Government  Source  Codes 

SEI=  Software  Engineering  Institute 
AJPO  *  Ada  Joint  Program  Office 
WPAFB  =  Wright  Patterson  Air  Force  Base 
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CECOM  »  Communications  Electronic  Command 
USAF  »  United  States  Air  Force 

A  J  Jl  AdalC  File  Directory 

The  information  in  Table  A-1  was  listed  in  die  AdalC  Bulletin  Board  in  March  1992. 
It  details  the  types  of  informadmi  available  from  AdalC. 

Table  A-1.  AdalC  IHrectories 


Directory  Numbers  and  General  Description  of  Contents* 


1  Ada  Information  Files 

2  Language  Reference  Manual 

3  Aj^roved  Ada  Commentaries 

4  Ada  Language  Rationale 

5  CAIS  Document 

6  AdalC  Newsletter 

7  Catalog  of  Resources  for 
Education  (CREASE) 


8  Miscellaneous- 
Unzipping  Utilities 

9  APSE  E&V  Guidebook  V2.0 

10  APSE  E&V  Reference  Manual 

11  Proposed  Ada  Style  Guide 

12  ASR  User’s  Handbook  Sc 
Directory 


*  To  list  Directory,  type  1:1 

For  a  list  of  all  available  files  on  the  system,  download  director.zip 


AdalC  Information  Files— Directory  1 

This  directory  contains  electronic  copies  of  the  flyers  and  other  documents  offered  by 
AdalC.  In  addition,  it  contains  electronic  copies  of  several  DOD  directives  relating  to 
the  Ada  programming  language. 

The  files  below  are  listed  with  the  extension  *.HLP”.  When  you  use  the  download 
comnumd,  you  will  be  prompted  for  the  fUmiame.  If  you  give  the  filename  with  the 
.HLP  extension,  you  will  get  an  ordinary  ASCII  text  file.  However,  to  reduce  the  time 
required  for  dov^oading  to  your  computer,  most  of  the  files  listed  bdow  are  also 
available  in  compressed  (ZIPped)  format.  To  download  a  file  in  compressed  format, 
substitute  .ZIP  for  the  .HLP  extension. 

To  view  these  ZIPPED  files,  you  need  an  unapping  utility,  which  is  available  on  this 
and  many  other  bulletin  boards.  (See  Directory  8  and  Bulletin  2.) 
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Fife  Name 

Updated 

Size 

Contents 

3405-1 

7/18/89 

18644 

Text  of  4/2/87  DOD  Directive 
3405.1,  Computer  Programming 
Language  Policy 

3405-2 

7/10/89 

7709 

Text  of  3/30/87  DoD  Directive 
3405.2  mandating  use  of  Ada 
language  in  computers  int^ral  to 
wea^xm  systems 

9XDDN 

7/09/91 

6144 

Access  to  Ada  9X  information  on 
DDN 

9XNEWS 

2/10/92 

6144 

Copy  of  the  most  recent  Ada  9X 
Re^rt  to  the  Public 

9XORDER 

11/05/91 

4096 

How  to  order  Ada  9X  documents 

ABSTRACT 

12/20/91 

20480 

Abstracts  of  Ada-related  articles 

ACEC 

8/15/91 

61440 

How  to  obtain  the  Ada  Compiler 
Evaluation  Ctynbility  (ACEC), 
DOD’s  compiler-performance  test 
package 

ACVC 

4/29/91 

40960 

How  to  obtain  a  copy  of  the  latest 
Ada  Compiler  Validation  Capability 
(ACVC),  die  validation  test  suite 

ADA-BIB 

10/15/91 

2048 

How  to  obtain  the  AJPO’S  Ada 
Bibliogrsqphy,  Volumes  1,  n,  and  m 
(1983-1986)  and  description 

ADA-CALR 

1/30/92 

10240 

List  of  upcoming  conferences, 
symposia,  and  programs  on  Ada 
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ADA-DDN 

8/06/91 

6144 

How  to  access  ajpo.sei.cmu.edu,  the 
ajpo  host  on  the  DDN 

ADA-PROD 

8/07/91 

22528 

List  of  articles  and  books  on  Ada 
costing,  sizing,  and  productivity 

ADA-RBBS 

2/06/92 

6144 

How  to  access  the  AdalC  Bulletin 
Board  at  (703)  614-0215  or  (301) 
459-3865 

ADA-USE 

3/14/91 

164839 

Sumnuuy  of  the  Ada  Usage 
Database,  which  lists  reported  Ada 
projects  from  around  the  world 

ADABOOKS 

2/10/92 

40960 

Books  relating  to  the  Ada 
Programming  Language 

ADACPLUS 

12/20/91 

24576 

Summary  of  Ada  versus  C++ 
Business  Case  Analysis  Rqwrt 

ADAIC 

2/06/92 

14336 

A  description  of  services  offered  by 
AdalC 

ADANET 

3/15/91 

4096 

Text  of  AdaNet’s  Executive 
Summary  describing  its  on-line 
services 

ADATODAY 

2/06/92 

24576 

On-line  newsletter  of  current  events 
and  developments  relating  to  Ada 

ADAYEST 

2/04/92 

36864 

Items  archived  from  Ada  Today 
(ADATODAY.HLP) 

AEO-SEO 

1/14/92 

4096 

Current  list  of  Software  Executive 
Officials  (formerly  AEO) 

AF-1MP89 

7/18/89 

29081 

Text  of  1/1/89  Air  Force  Ada 
Implementation  Plan 
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AF-INT91 

8/12/91 

2048 

Text  of  Air  Force  1991 
Interpretation  of  Congressional 
Mandate 

AF-POL88 

11/09/88 

41809 

Text  of  11/9/88  Air  Force  policy  on 
programming  languages 

AF-POL90 

12/21/90 

10868 

Text  of  8/7/90  Air  Force  policy  (Hi 
programming  languages 

AI-ADA 

8/12/91 

24576 

Ada  and  AI  documents  available 
from  DTIC  and  NTIS 

AJPO-891 

10/28/91 

6144 

Article  announcing  that  SPC’s  guide 
would  be  AJPO’s  suggested  Ada 
style  guide  (with  ordering 
information) 

ARCHIVES 

11/02/89 

18341 

Items  archived  from  Ada  Yesterday 
(ADAYEST.HLP)  that  are  mote 
than  1  year  old 

ARMIMP90 

7/16/90 

17928 

Text  of  7/16/90  Army  Ada 
Implementation  Plan 

ASEETUB 

4/10/91 

16446 

Training-related  materials  in  the 
ASEET  Materials  Library  at  the 
AdalC 

ATIP-F89 

4/24/91 

18432 

Projects  assisted  by  the  Ada 
Technology  Insertion  Program  in 
FY89 

BENCHMRK 

7/30/91 

12288 

How  to  obtain  various  benchmark 
performance  test  suites 

BINDINGS 

2/04/92 

73728 

Available  Ada  bindings 

CLAS-SEM 

2/06/92 

51200 

Classes  and  seminars  rdating  to  the 
Ada  language 
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CREASE 

11/27/91 

2048 

How  to  obtain  AJPO’s  April  1988 
CREASE  Version  5.0 

CREASFOR 

Ada  Education  Survey  form  for 
CREASE  Ver.  6.0 

DEF-MCCR 

3/04/83 

4795 

Text  of  3/4/83  DOD  guidelines  for 
acquiring  computer  resources 
(defines  mission-critical  computer 
resources) 

DCX:U-REF 

12/05/91 

20480 

List  of  Ada-related  documents 
available  through  DTIC/NTIS  and 
information  on  how  to  obtain  them 

DOORS 

7/09/91 

6144 

AdalC  Databases  Available,  On-line 
Ada  Products  and  Tools,  and  Ada 
Pragma  Support 

EMBDSYS 

9/09/91 

34816 

Abstracts  of  documents  and  articles 
on  Ada  and  embedded  systems 

FAA.ADA 

11/07/89 

6207 

Text  of  10/20/89  FAA  Action 
Notice  for  mandating  the  use  of  Ada 
in  acquisition  and  major 
modifications 

GENINTRO 

10/10/91 

2048 

Cover  letter  to  accompany  General 
Information  Packet 

GLOSSARY 

8/11/90 

47056 

Ada-related  terms  and  their 
meanings 

GRAMMAR 

10/04/89 

37569 

*A  LALR(l)  Grammar  for  ANSI 
Ada”  by  Gerry  Fisher  and  Phillipe 
Charles,  1983 

mSTADA 

11/26/91 

26624 

"The  History  of  Ada"-March  1984 
article  by  Robert  DaCosta 
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IMP  '  ’JIDE 

11/26/91 

2048 

KO-STAT 

11/26/91 

10240 

LADY-LOV 

11/25/91 

10240 

LRM 

11/26/91 

4096 

MAIL_DDN 

8/20/91 

51200 

MANDAT90 

1/28/92 

6144 

MARIMP88 

3/09/88 

32563 

NATO-ADA 

11/26/91 

2048 

NAVIPL91 

11/26/91 

20480 

CXJDBIB 

9/05/91 

34816 

REALTIME 

6/19/91 

40960 

How  to  obtain  the  Ada  Compiler 
Validation  Capability  Implementers’ 
Guide  (1986) 

Background  informatimi  on  the 
ISO’s  accq)tance  of  Ada  as  an 
international  standard 

Article  on  life  of  Ada  Lovelace  by 
Carol  L.  James  and  Duncan  E. 
Morrill  with  note  on  the  naming  of 
the  Ada  language 

How  to  obtain  the  Ada  Language 
Reference  Manual,  ANSI/ 
MIL-STD-1815A  1983 

A  list  of  UNIX  public-access  sites 
that  can  be  used  to  send  E-mail  to 
hosts  on  the  DDN 

Text  of  the  Congressional  Ada 
mandate— plus  some  background 

Text  of  9  Jan  1988  Marine  Corps 
Ada  Implementation  Plan 

Text  of  1985  AJPO  announcement  of 
NATO’s  adoption  of  Ada  as  a 
common  High  Order  Language 
(HOL)  in  military  systems 

Interim  Dqnrtmoit  of  the  Navy 
Policy  on  Ada,  24  Jun  1991 

list  of  articles  and  documents  on 
Ada  and  Object-Orioited  Design 
(OOD) 

List  of  publications  on  Ada  used  in 
real  time  jobs 
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REPOSTRY 

11/26/91 

14336 

How  to  obtain  programs  and  tools 
from  the  Ada  Software  Rq)ositoiy 
on  SIMTEL20 

REUSCODE 

2/06/92 

16384 

Sources  of  Ada  source  code, 
reusable  components,  and  software 
repoutories 

REUSEPUB 

9/16/91 

24576 

List  of  publications  relating  to  the 
reuse  of  Ada  source  code 

SERIALS 

11/26/91 

12288 

List  of  serial  publications  that 
feature  information  on  the  Ada 
language  and  the  Ada  community 

STYL-ORD 

11/05/91 

2048 

Ordering  information  and  order  form 
to  order  version  2  of  Ada  Quality 
and  Style 

SUCCESS 

10/17/91 

34816 

Reprint  of  article  from  Military  A 
Aerospace  Elearonics 

TNG-TAPE 

11/25/91 

20480 

Description  and  ordering  information 
for  a  19-tape  series  of  Ada  training 
videotapes 

TRADEMRK 

4/23/91 

6144 

Text  of  1987  AJPO  announcement 
that  Ada  trademark  is  rq)laced  by 
certification  mark 

VAL-COMP 

2/05/92 

123280 

List  of  the  currently  validated  Ada 
compilers 

VAL-DOC 

7/03/91 

2048 

Instructions  on  how  to  obtain  the 
Ada  Compiler  Validation  Procedures 

VAL-NOV 

12/01/90 

145846 

List  of  validated  Ada  compilers  as  of 
Nov  90— kq>t  for  information 
purposes 
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VAL-PROC 

9/19/90 

55320 

Text  of  the  Ada  Compiler  Validaticm 
Procedures,  Version  2.1,  August 
1990 

VALCOVER 

4/16/91 

2048 

Cover  letter  to  accompany 
Validation  packet 

VALFACIL 

12/04/91 

2048 

List  of  Ada  Validation  Facilities 
(AVFs)  performing  Ada  Compiler 
Validation  Oqrability  tests 

VSR-DOCU 

7/03/91 

24576 

List  of  Validation  nummary  Rqwrts 
(VSRs)— results  from  testing  of 
compilers— and  how  to  order  info, 
from  DTIC/NTIS 

WTTHDRWN 

8/05/91 

8192 

Tests  that  have  been  withdrawn  from 
the  validation  test  suite,  ACVC  1.11 

X-SURVEY 

11/01/91 

12288 

X/Ada  binding  user  questionnaire  of 

the  X/Ada  Study  Team  at  GHG 
Corporation 
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AJ  OTHER  SOURCES 

The  information  on  commercial  and  nonprofit  organizations  cited  below  is  provided  to 
help  the  DON  Program  Manager  become  knowledgeable  about  Ada-related  issues.  These 
sources  are  not  endorsed  by  the  DON.  They  are  provided  to  augment  the  list  of 
Government  sources  in  Section  A.  1  and  to  he’n  Program  Managers  become  fomiliar  with 
the  wide  array  of  available  sources. 

Other  sources  (e.g.,  organizations,  training,  publications,  tools)  to  be  ccxisidered  for 
incluaon  in  future  editions  of  the  Ada  Implementation  Guide  should  be  sent  to  the 
following  address: 

Commander 

Space  and  Naval  Warfare  Systems  Command 
SPAWAR  2241  (CDR  M.  Romeo) 

2451  Crystal  Drive 
Washington,  D.C.  20363-5100 

AJ.l  Training 

AdaWorics 

261  Hamilton  Avenue 

Suite  320E 

Palo  Alto,  CA  94301 

Attn.:  Richard  Riehle 

(415)  328-1815 

FAX:  (415)328-1112 

Internet:  riehler@ajpo.sei.cmu.edu 

AdaWorks  trains  DOD  personnel  in  all  aspects  of  Ada  software  development.  Courses 
range  from  introductory  through  advanc^  Ada  and  include  material  tailored  to  the 
q)ecial  needs  of  Management  Information  Systems  (MIS)  and/or  COBOL  programmers 
and  analysts,  scientific  and  embedded  systems  developers,  and  experienced  software 
engineers.  AdaWorks  also  provides  Ada  and  software  engineering  training  by  giving 
project  experience  through  a  mentoring  process. 

Alsys 

5959  Cornerstone  Court  West 
San  Di^o,  CA  92121 
(619)  457-2700 

Alsys  has  been  a  major  Ada  compiler  vendor  for  the  last  9  years.  It  has  developed  a  set 
of  training  courses  tailored  to  the  installation  and  use  of  its  compiler  technology. 
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EVB  Software  Engineering,  Inc. 

5303  Spectnim  Drive 
Frederick.  MD  21701 
Attn.:  Jennifer  Jaynes  Lott 
(301)095-6960 
FAX:  (301)695-7734 

EVB  provides  several  courses  including,  but  not  limited  to.  Arbi  Programmiiig.  OOD  and 
requireinent  analyris.  XWindows.  and  software  reuse  in  Ada  and  software  development. 

Fbstrak  Training  Inc. 

(Quarry  Park  Place 
9175  GuUford  Road 
Suite  300 

Columbia.  MD  21046-1802 
(301)  924-0050 

Fastrak  presents  both  on-site  and  public  courses  in  software  engineering,  object-oriented 
teduKdogy.  and  the  Ada  language. 

Reifer  Crmsultaiits  Inc. 

Mariceting  Manager 
Reifer  Consultants  Inc. 

P.O.  Box  4046 
Torrance.  CA  90510 
(310)  373-8728 
FAX:  (310)373-9845 

Reifer  (Consultants  Inc.,  founded  in  August  1980.  focuses  primarily  on  consulting  in  Ada 
transition  metrics,  risk  analysis,  and  cost  estimating.  Iliey  maricet  a  software  sizing 
modd  and  an  Ada  costing  pacloge.  Training  for  these  packages  is  provided  through 
ptfolic  and  on-site  seminars. 

Texd  Company 

Victoria  Plaza.  Building  4,  no.  9 
615  Hqie  Road 
Eaton.  NJ  07724 
(201)  992-0232 

Texd  specializes  in  Ada  education  and  training  consulting.  IndqioKtent  Validation  aid 
Verification  (IV&V).  and  i^lication  devdqiroent. 
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Unlterdtles  and  Colleges  (Civilian) 

The  following  universities  and  colleges  are  currently  teaching  Ada  as  the  first  language 
to  their  entering  nuyors  (Feldman,  92): 

Allan  Hancock  Collie,  California 

Birmingham  Southern  (^llq^e,  Alabama 

Califoi^  State  University,  Long  Beach,  Califoniia 

California  State  University,  Northridge,  California 

California  Polytechnic  State  University,  San  Luis  ObiqK>,  California 

Cypress  Collie,  California 

Embry-Riddle  Aeronautical  University,  Florida 

Flcmda  Institute  of  Technology,  Florida 

Fayetteville  State  University,  North  Carolina 

The  George  Washington  University,  Washington,  D.C. 

Indiana-Putdue  University,  Ft.  Wayne,  Indiana 

LeMoyne  College,  New  York 

Marion  County  Technical  Center,  West  Virginia 

Marshall  University,  West  Virginia 

Muskingum  College,  Ohio 

Norwich  University,  Vermont 

Oklahoma  City  University,  Oklahoma 

Otterbein  College,  Ohio 

Saint  Mary  College,  Kansas 

Sam  Houston  State  University,  Texas 

San  Di^o  Mesa  Collie,  California 

Southern  Aricansas  University,  Arkansas 

State  University  of  New  York  at  Plattsburgh,  New  York 

Stockton  State  College,  New  Jersey 

University  of  Dayton,  Ohio 

University  of  New  Orleans,  Louisiana 

University  of  South  Dakota,  South  Dakota 

University  of  South  Florida,  Florida 

Univernty  of  Washington,  Wadiington 

West  Virginia  University,  West  Virginia 

The  following  universities  and  colleges  first  introduce  Ada  in  their  CS2  or  Data 
Structures  courses  (Feldman,  92): 

Briar  Cliff  College,  Iowa 

California  Polytechnic  State  University,  Pomona,  California 
California  State  University,  Fullerton,  California 
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CoU^  of  West  Viiginia,  Beckley,  West  Virginia 
Daniel  Wd>ster  CoU^e,  New  Hampshire 
Florida  Intematitmal  University,  Rorida 
Gallaudet  University,  Washington,  D.C. 

Georgia  State  University,  Georgia 

Indiana  University,  New  Albany,  Indiana 

Lenoir  Rhyne  Collide,  North  Carolina 

Mesa  State  Collie,  Colorado 

Mooter^  Peninsula  Collie,  California 

Murray  State  University,  Kentucky 

National  Univerrity,  Criifomia 

Nordiem  Arizona  University,  Arizona 

Northern  Kentucky  University,  Kentucky 

Northeast  Missouri  University,  Missouri 

Ogl^horpe  University,  Georgia 

(^o  University,  Athens,  Ohio 

Pennsylvania  State  University,  Harrisburg,  Pennsylvania 

Portland  State  University,  Oregon 

Rose  Hulman  Institute  of  Technology,  Indiana 

Southwest  Biyrtist  College,  Missouri 

Shippensburg  University,  Pennsylvania 

United  States  Air  Force  Academy,  Colorado 

University  of  Alaska,  Fairbanks,  Alaska 

University  of  Missouri,  Columbia,  Missouri 

University  of  Richmond,  Viiginia 

University  of  Scranton,  Pennsylvania 

Western  New  England  Collie,  Massachusetu 

Publications 

AdaDATA  Newsletter 

International  Resource  Development,  Inc. 

P.O.  Box  1716 
New  Canaan,  CT  06840 
(203)  966-2525 

This  monthly  newsletter  covers  market  trends  and  commercial  devdopments  in  Ada 
software,  services,  and  equipment.  The  cost  of  a  subscription  is  $445  per  year. 
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4da  Lettors 

Association  for  Computing  Machinery,  Inc. 

IS  15  Broadway 

New  York,  NY  10036 

(212)  869-7440 

Attn.:  Membership  Services 

Internet:  acmhelp®acmvm.bitnet 


This  bimonthly  publication  for  the  ACM  SIGAda  has  been  published 
newsletter  contains  technical  Ada  articles  as  weU  as  a  calendar  of 
subscription  costs  $20  per  year  for  ACM  members  and  $35  ^ 
Annual  ACM  membership  dues  are  $79  for  nonstudents  and  $24  for 
$42  per  year  to  become  a  SIGAda  member  only.) 


since  1981.  The 
Ada  events.  (A 
for  nonmembers, 
students.  It  costs 


Ada  Newsletter 

Raytheon  Equipment  Division 
Tim  Boutin,  Editor 
MS  5-2-508 
Sudbury,  MA  01776 
(508)  440-3607 

This  newsletter  tracks  developments  in  the  Ada  language  through  conference  rqxwts  and 
provides  vendor  news  articles  and  a  listing  of  Ada  events.  There  is  no  charge  for  this 
publication. 


Ada  Rendezvous 

Texas  Instruments  Incorporated 

David  G.  Struble 

Software  Engineering  Department 

MS  8489 

P.O.  Box  869305 

Plano,  TX  75086 

(214)  575-5346 

Ada  Rendezvous  is  a  free  annual  publication.  Articles  qian  multiple  areas  of  intere^, 
including  results  of  Ada  compiler  evaluations  for  embedded  targ^,  review  of  Ada  tools, 
and  technic^t  information  contributed  by  Ada  developers.  Such  articles  provide  guidance 
to  iqiplication  programmers  on  how  to  use  Ada  with  specific  hardware  architecturKaiw 
microprocessor  designs.  Ada  Rendezvous  also  addr^  evolving  Government  and  DOD 
that  affect  existing  and  proposed  contracts  with  Ada  requirements. 
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Ada  Strategies 

Ralph  E.  Crafts,  Editor  and  Publisher 
Rraite  2,  Box  713 
Harpers  Ferry,  WV  25425 
(304)  725-6542 

This  monthly  newsletter  covers  Ada  business  strat^ies  and  contract-evaluation 
guidelines.  It  provides  information  on  Ada  policy  and  trends  and  on  Congressional  and 
funding  issues  as  well  as  insight  concerning  current  l^islaticm.  The  aimual  cost  is  $100 
for  Government  subscribers. 

CAIJWG  Report 
Alsys,  Inc. 

67  South  Bedford  Street 
Burlington,  MA  01803-5152 
(617)  270-0030 

This  newsletter  for  members  of  ACM  SIGAda’s  Commercial  Ada  Users  Working  Group 
(CAUWG)  contains  news  and  comments.  It  is  available  to  the  public  at  no  charge. 

FRAWG  Newsletter 

Martin  Marietta  Aerospace 
MS1J0420 
P.O.  Box  179 
Denver,  CO  80201 
(303)  971-6731 

This  newsletter  is  a  publication  of  the  Front  Range  Ada  Working  Group  (FRAWG). 
That  is  no  charge  for  this  publication. 

Software  Engineering  Notes 

Association  of  Computing  Machinery,  Inc. 

1515  Broadway 
New  York  City,  NY  10036 
(212)  869-7440 
acmhelp®acmvm.bitnet 


A-B6 


Department  of  the  Navy 


Helpful  Sources 


This  quarterly  is  an  informal  publicatitm  of  the  ACM  Special  Interest  Group  on  Software 
EngiiuBering  (SIGSOFT),  which  is  concerned  with  the  design  and  development  of  high- 
quality  software.  (A  subscription  costs  $16  per  year  for  ACM  members  and  $38  for 
affiliate  nonmemben.  Annual  ACM  membership  dues  are  $75  for  nonstudents  and  $22 
for  students.) 

SFC  Quarterly 
SPC  Bmlding 
2214  Rock  Hill  Road 
Herndon,  VA  22070 
(703)  742-8877 

The  SPC  Quarterfy  is  published  by  the  Software  Productivity  Consortium  (SPC)  for 
unlimited  distribution  to  its  member  companies,  as  well  as  to  commercial,  government, 
and  academic  organizations.  SPC  helps  its  member  companies  to  develop  the  processes, 
methods,  tools,  and  services  needed  to  significantly  improve  the  d^gn  and 
implementation  of  high-quality,  software-intensive  systems.  Its  methods  seek  to  make 
the  Ada  software  developer  more  productive.  Use  of  these  methods  helps  bridge  the  gap 
between  well-established  software  engineering  principles  and  the  actual  practice  of 
programming  in  Ada.  There  is  no  charge  for  this  publication. 

A.33  Repositories 

COSMIC,  University  of  Georgia 
382  East  Broad  Street 
Athens,  GA  306Q2 
(706)  542-3265 
FAX:  (706)542-4807 

COSMIC  distributes  NASA-developed  software  including  string,  numerical,  service,  and 
linear  algebra  subprograms.  Many  are  oriented  to  avionics  applications.  Source  code 
is  provided  with  the  software  purchase,  and  a  free  brochure  is  available. 

EVB  Software  Ekigiiieeiliig,  Inc. 

5303  Spectrum  Drive 
Frederick,  MD  21701 
1-800-877-1815 
(301)  695-6969 
FAX:  (301)695-7734 

Generic  Reusable  Ada  Components  for  Engineering  (GRACES  is  a  library  of  275  Ada 
software  components  based  on  commonly  used  data  structures  such  as  strings,  trees,  and 
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grairiis.  Each  component  includes  complete  design  documentaticHi,  source  code,  and  at 
least  (Hie  test  program.  GRACE  is  completely  portable.  Its  only  requirement  is  a 
validated  Ada  compiler.  Free  samples  are  available. 

IWG  Corp. 

1940  Fifth  Avenue 
Suite  200 

San  Diego,  CA  92101 
(619)  531-0092 
FAX:  (619)531-0095 

Proplink  is  an  Ada  program  for  analysis  of  communication  link  propagation  paths  ftom 
Extremely  Low  Frequency  (ELF)  to  Extremely  High  Frequency  (EHF)  using  £ut-ninning 
models. 

MassTech,  Inc. 

3108  Hillsboro  Road 
Huntsville,  AL  35805 
(205)  539-8360 
FAX:  (205)533-6730 

Math  Pack  contains  over  320  Ada  mathematical  subprograms  in  19  reusable  generic  Ada 
pack^es.  It  includes  linear  algebra,  linear  system  solutions,  integration,  differential 
equatums,  eigensystems,  interpolation,  probability  functions,  Fourier  transforms,  and 
transcendental  functions.  Purchase  includes  source  axle,  documentation,  on-line  help, 
and  tdq)hone  support. 

Rockwell  International  Corporation 

Manager,  Software  Engineering  Process  Group 

M/S  460-220 

3200  East  Renner  Road 

Richardson,  TX  75082-2402 

(214)  705-0000 

Rockwell  International  Corporation  nuunuuns  a  database  server  that  cemtains  the  Ada 
t(x>ls  set.  It  also  maintains  two  libraries.  One  contains  the  implementor’s  tools  and  the 
other  is  a  library  of  implemented  software. 

Wizard  Software 

2171  South  Parfet  Court 
Lakewood,  CO  80227 
(303)  986-2405 
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Booch  components  feature  data  types  and  tools  for  sorting,  searching,  and  character 
matching.  Each  abstraction  has  multiple  implementations  and  follows  OOD.  Source 
code  is  provided.  A  version  in  C++  is  also  available.  These  products  are  d.so 
marketed  in  Europe  and  Japan. 

A.3.4  Conferences  and  Special  Interest  Groups 

SIGAda 

Mr.  Mark  Gerhardt 
ESL,  Inc.  MS  G1 
495  Java  Drive 
Sunnyvale,  CA  94088-3510 
(408)  752-2459 
(408)  738-2888  (switchboard) 

SIGAda  is  a  professional  society  dedicated  to  the  dissemination  of  information  about  all 
aspects  of  the  Ada  programming  language,  including  standardization,  implementation, 
usage,  policy,  management,  and  education.  It  sponsors  meetings  several  times  a  year 
and  also  publishes  a  bimonthly  newsletter,  Ada  Letters.  Originally  known  as  AdaTEC, 
SIGAda  was  established  under  the  auspices  of  ACM  in  1981.  In  addition  to  the  national 
SIGAda  organization,  there  are  approximately  50  chartered  local  SIGAda  chapters.  Most 
of  these  local  chapters  hold  technical  meetings  on  a  monthly  basis.  The  point  of  contact 
for  each  local  chapter  is  published  in  Ada  Letters.  The  Washington,  D.C.,  chapter  of 
SIGAda  holds  an  annual  symposium  on  Ada. 

Tri-Ada  Conference 

Danieli  &  O’Keefe  Associates,  Inc. 

Chiswick  Park 
490  Boston  Post  Road 
Sudbury,  MA  01776 
(508)  443-3330 

1-800-833-7555  (in  the  United  States  and  Canada  only) 

FAX:  (508)443-4715 

Tri-Ada,  SIGAda’s  major  annual  conference  and  exposition,  combines  the  availability  of 
lectures  about  the  technology  and  management  of  the  latest  developments  in  the  Ada 
community  with  in-depth  presentations  on  project  experience.  The  conference  offers 
tutorials,  birds-of-a-feather  sessions,  and  the  opportunity  to  see  the  Ada  products  and 
services  available  in  the  marketplace.  In  addition,  information  gathered  in  the  coffee 
klatches  and  informal  gatherings,  which  always  occur  at  these  meetings,  is  not  obtainable 


Ada  Implementation  Guide 


A-59 


Helpful  Sourcn 


in  any  other  way.  Tri-Ada  presents  a  unique  opportunity  to  be  immersed  in  the 
hsq>pc^gs  in  the  world  of  Ada  so  that  organizations  can  become  or  continue  to  be  at  the 
fordiont  of  Ada  understanding  and  use. 

Washington  Ada  Symposium 
Washington,  D.C.  SIGAda 
(301)  286-7631 
Ed  Seidewitz 

At  the  Washington  Ada  Symposium  (WAdaS),  information  is  presented  on  software 
engineering  dealing  with  commercial  industry.  Government,  military,  scientific, 
academia,  weapons,  and  administration  with  regard  to  Ada. 

A.3.S  Operational  Development  Support  Tools 

ObJectMaker 

Mark  V  Systems  Limited 
16400  Ventura  Boulevard,  Suite  303 
Endno,  CA  91436 
(818)  995-7671 

ObJectMaker  (formerly  Adagen)  is  a  CASE  tool  that  supports  object-oriented 
diagramming  methods  for  requirements  analysis  and  top-level  and  detailed  design.  User- 
interface  and  diagram  types  are  tailorable.  Optional  language  modules  automatically 
generate  compilable  code  (C,  C+ +,  or  Ada)  from  detailed  design  diagrams  and  support 
reverse  engineering.  The  language  module  reverse  engineering  toolset  takes  legal  code 
(C,  C++,  or  Ada)  back  to  multiple-level,  nested,  and  detailed  design-level  diagrams. 
This  is  powerful  for  reuse  and  reengineering  as  well  as  documenting  as-built  code  and 
component  libraries.  Older  methods  supported  include  data  flow  diagrams,  real-time 
mctensions,  entity  relationship,  state  transition,  and  structure  charts.  ObJectMaker  is 
available  on  Digital  Equipment  Corporation,  Sun,  Apollo,  Hewlett-Packard,  MIPS,  and 
Data  General  Aviion  workstations  as  well  as  on  Macintoshes  and  IBM  PCs. 

EVB  Software  Engineering,  Inc. 

5303  Spectrum  Drive 
Frederick,  MD  21701 
Attn.:  Jennifer  Jaynes  Lott 
(301)  695-6960 
FAX:  (301)695-7734 

GRAMMI  is  an  Ada  user  interface  toolkit  that  supports  the  development  of  Ada 
Gr^hical  User  Interfaces  (GUIs)  using  the  XWindows  system.  GRAMMI  supports  the 
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n^id  prototyping  and  evolutionary  development  of  Ada  user  interface  software  with  an 
integrated  set  of  tools  that  helps  users  to  interactively  build  screois  and  generate  the 
resulting  Ada  code.  GRAMMI  User  Interfaces  are  designed  to  support  the  full  features 
of  Ada  programs,  including  Ada  tasking  and  exception  handling. 

HERAGRAPH  is  a  two-  or  three-dimensional  graphics  application  framework  that 
enables  the  development  of  high-performance,  interactive  graphics  s^lications.  Use  of 
HERAGRAPH’s  reusable  graphical  objects.  Motif  style  user  interface  components,  and 
aq[)plication  framework  frees  users  to  concentrate  on  developing  the  functionality  of  their 
s^lications.  Writtm  in  Ada,  HERAGRAPH  provides  an  industrial-strength  solution  for 
the  development  of  today’s  modem  and  complex  graphics  applications  on  both  DOS  and 
UNDC/XWindows  platforms.  HERAGRAPH  has  bm  used  successfully  in  a  variety  of 
interactive,  high-performance  graphics  applications.  Domains  include  Geographic 
Information  Systems  (GISs),  Range  Control  Applications,  Railway  and  Tran^rtation 
Control  systems.  Interactive  Graphical  Dau^ase  Editor  applications,  Gr:q)hical 
Simulation  Systems,  and  Graphical  Training  Systems. 

REUSE  LIBRARY  TOOLSET  (RLT)  is  an  integrated  set  of  tools  that  supports  the 
definition,  population,  and  searching  of  a  software  reuse  library.  Software  components 
in  RLT  are  classified  using  a  faceted/attribute  classification  schema.  Defining  and 
populating  a  reuse  library  with  RLT  is  performed  entirely  through  a  point-and-click  GUI. 
The  search  and  retxievi  screens  are  automatically  generated.  T^ere  are  no  cryptic 
commands  to  learn  or  files  to  edit.  RLT  can  be  used  to  maintain  large  repositories  of 
reusable  software,  yet  it  is  easy  enough  for  individual  engineers  to  organize  their  own 
personalized  libraries. 

EVB  Object-Oriented  Development  Method/CASE  Tool  Support.  This  tool  is  supported 
by  Paradigm  Plus  by  ProtoSoft.  Paradigm  Plus  is  a  configurable  CASE  tool  that  uses 
the  object-oriented  model  to  provide  support  to  a  wide  range  of  software  engineering 
activities  throughout  the  software  life  cycle.  The  tool  is  in  use  in  more  than  200 
installations  world  wide.  On  the  EVB  edition  of  Paradigm  Plus,  EVB  provides  all 
customer  support  for  the  product.  Questions  about  methodologies  are  answered  directly 
by  the  source,  assuring  you  of  accurate  answers  at  aU  times.  This  tool  provides  all  the 
graphical  notations  and  rules  necessary  to  develop  Ada  systems  using  the  EVB  object- 
oriented  approach. 
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Appendix  B 

Department  of  the  Navy  Standards,  Policies  and 
Procedures 


This  appendix  provides  a  list  of  DOD/DON  software  policies  in  the  following  categories: 

DOD  Directives,  Instructions,  and  Standards 
DON  Policies  including: 

Secretary  of  the  Navy  Instructions 

Naval  Operations  Instructions 

Marine  Corps  Orders 

Naval  Air  Systems  Command  Instructions 

Naval  Sea  Systems  Command  Instructions 

Space  and  Naval  Warfare  Systems  Command  Instructions 

AV  Documents 

Military  Standards 
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Appendix  C 

The  Maturity  Framework 

The  maturity  firamework  for  characterizing  the  status  of  a  software  process  identifies  five 
maturity  levels.  This  framework  is  intended  for  use  in  conjunction  with  an  assessment 
mediodology  and  a  management  system.  Assessment  provides  a  way  to  identity  the 
organization’s  specific  maturity  status,  and  the  management  system  establishes  a  structure 
for  actually  implementing  the  main  actions  needed  to  improve  the  organization. 

A  maturity  level  is  a  well-defined  evolutionary  plateau  on  the  path  toward  becoming  a 
mature  software  organization.  Each  level  is  a  layer  in  the  foundation  for  ccmtinuous 
process  improvement.  The  five  maturity  levels  in  the  Software  Engineering  Institute 
(SEI)  Capability  Maturity  Model  (CMM)  are  defined  as  follows: 

*  Initial—At  this  level,  the  organization  typically  does  not  provide  a  stable 
environment  for  developing  and  maintaining  software.  The  software  process  is 
constantly  changed  or  modified  as  the  work  progresses.  Until  the  process  is  under 
statistical  control,  orderly  progress  in  process  improvement  is  impossible. 

*  Repeatable— Basic  project  management  processes  are  established  to  track 
commitments,  cost,  schedule,  changes,  and  fimctionality.  The  necessary  process 
discipline  is  in  place  to  repeat  earlier  successes  on  projects  with  similar 
applications. 

*  Defined— The  software  process  for  both  management  and  engineering  activities  is 
documented,  standardized,  and  integrated  into  an  organization-wide  software 
process.  All  projects  use  a  documented  and  approved  version  of  the  organization’s 
process  for  developing  and  maintaining  softw^.  At  this  point,  it  is  prK4)£d>le  that 
advanced  technology  can  be  usefully  introduced. 

*  Managed— Detailed  measures  of  the  software  process  and  product  quality  are 
collected.  Both  the  software  process  and  products  are  quantitatively  understood 
and  controlled  using  detailed  measures.  At  this  level,  the  most  significant  quality 
improvements  begin  to  appear. 

*  Optimized— With  a  measured  process  in  place,  the  foundation  exists  for  continuing 
improvement  and  optimization  of  the  process.  Continuous  process  improvement  is 
enabled  by  quantitative  feedback  from  the  process  and  from  testing  innovative 
ideas  and  technology. 
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The  subsections  below  contain  additional  infonnation  on  the  Initial  and  Rq)eatable 
Processes. 


C.l  INITIAL  PROCESS 

The  following  paragraphs  on  the  Initial  Process  are  from  the  Camogie-Mellon 
University/Softwaie  Engineering  Institute  (CMU/SEI)  publication,  Charactermng  the 
Software  Process:  A  Maturity  Framework,  by  Watts  Humphrey  (CMU/SEI-87-TR-11, 
June  1987.) 

The  Initial  Process  could  properly  be  called  ad  hoc  or  chaotic.  Here,  the 
organization  typically  operates  without  formalized  procedures,  cost  estimates,  and 
project  plans.  Tools  are  not  well  integrated  widi  die  process  or  uniformly 
applied.  Change  control  is  lax  and  there  is  litde  senior  management  exposure  or 
understanding  of  the  problems  and  issues.  Since  problems  are  often  deferred  or 
even  forgotten  rather  than  solved,  software  inst^tion  and  maintenance  often 
present  serious  problems. 

While  organizations  at  the  Initial  Process  may  have  formal  procedures  in  place 
for  project  control,  there  is  no  management  mechanism  to  assure  that  they  are 
used.  The  best  test  is  to  observe  how  such  an  organization  behaves  in  a  crisis. 

If  it  abandons  established  procedures  and  reverts  to  merely  coding  and  testing,  it 
is  likely  to  be  at  the  Initisd  Process.  In  essence,  if  the  process  is  appropriate,  it 
must  be  used  in  a  crisis  and  if  it  is  not  appropriate,  it  should  not  be  us^  at  all. 

One  key  reason  why  organizations  behave  in  this  chaotic  fashion  is  that  they  have 
not  gained  sufficient  experience  to  understand  the  consequences  of  such  behavior. 
Since  many  effective  software  actions  such  as  design  and  code  reviews  or  test 
data  analysis  do  not  appear  to  directly  support  shipping  the  product,  they  seem 
expendable.  It  is  much  like  driving  an  automc^ile.  Few  drivers  with  any 
experience  will  continue  driving  for  very  long  when  the  engine  warning  light 
comes  on,  regardless  of  their  rush.  Similarly,  most  drivers  starting  on  a  new 
journey  will,  regardless  of  their  hurry,  pause  to  consult  a  map.  They  have 
learned  the  difference  between  speed  and  progress.  In  software,  coding  and 
testing  seem  like  progress  but  they  are  often  only  wheel  spinning.  While  they 
must  be  done,  there  is  always  the  danger  of  going  in  the  wrong  direction. 
Without  a  sound  plan  and  a  thoughtful  analysis  of  the  problems,  there  is  no  way 
to  know. 

Organizations  at  the  Initial  Process  can  advance  to  the  Repeatable  Process  by 
instituting  basic  project  controls.  The  most  important  are; 
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1.  ProtJect  Management.  The  fundamental  role  of  a  project  management 
system  is  to  ensure  effective  control  of  commitments.  This  control 
requires  adequate  preparation,  clear  responsibility,  a  public  declaration, 
and  a  dedication  to  performance.  Software  project  management  starts  with 
an  understanding  of  the  magnitude  of  the  job  to  be  done.  In  all  but  the 
simplest  projects,  a  plan  must  be  developed  that  lays  out  the  most 
attainable  schedule  and  the  resources  requir^.  In  the  absence  of  such  an 
orderly  plan,  the  commitment  to  a  schedule  will  be  no  more  than  an 
educated  guess. 

2.  Management  Oversight.  A  suit2d>le  disciplined  software  development 
organization  must  have  corporate  oversight.  This  oversight  includes 
reviewing  and  approving  all  plans  for  major  developments  before  the 
organization  commits  to  the  developmoit  officially.  Quarterly  reviews  for 
each  project  must  be  conducted  to  determine  facility-wide  process 
compliance  and  quality  of  performance  in  the  field;  track  schedule  cost 
trends  and  computing  service;  and  check  quality  and  productivity  goals. 
The  lack  of  such  reviews  typically  results  in  unevoi  and  generally 
inadequate  implementation  of  the  process  as  well  as  frequent 
overcommitments  and  cost  surprises. 

3.  l¥oduct  Assurance.  A  product  assurance  group  is  charged  with  assuring 
management  that  the  software  development  work  is  being  done  as  it  should 
be.  To  be  effective,  the  assurance  group  must  report  directly  to  senior 
management  and  must  have  sufficient  resources  to  monitor  performance 
of  all  key  planning,  implementation,  and  verification  activities.  The  size 
of  the  product  assurance  group  generally  is  between  5%  and  10%  of  that 
of  the  development  organization. 

4.  Change  Control.  Control  of  changes  in  software  development  is 
fundamental  to  maintaining  business  and  financial  control  as  well  as  to 
technical  stability.  To  develop  high-quality  software  on  a  predictable 
schedule,  the  r^uirements  must  be  established  and  maintained  with 
reasonable  stability  throughout  the  development  cycle.  Changes  will  have 
to  be  made,  but  they  must  be  managed  and  introduced  in  an  orderly  way. 
Although  occasional  changes  are  essential,  evidence  indicates  that  most 
changes  can  be  deferred  and  phased  in  at  a  subsequent  point.  If  change 
is  not  controlled,  orderly  testing  is  impossible  and  no  quality  plan  can  be 
effective. 

C.2  REPEATABLE  PROCESS 

Organizations  at  the  Repeatable  level  can  advance  to  the  Defined  level  by 
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instituting  additional  process  controls.  The  most  important  controls  are  as 
follows: 

•  Standard  processes  for  developing  and  maintaining  software  across  the 
organization,  as  well  as  software  engineoing  and  software  managemoit 
processes,  must  be  documented  and  must  be  integrated  into  a  coherent 
whole.  The  organization  must  start  exploiting  effective  software 
engineering  practices  when  standardizing  those  software  processes.  A 
well-defined  software  process  will  provide  a  good  view  of  technical 
progress  on  all  projects  as  a  result  of  the  integration  of  all  ragineraing 
activities  related  to  those  projects. 

•  The  organization  must  establish  and  make  effective  use  of  a  Software 
Engineering  Process  Group  (SEPG)  to  facilitate  process  definition  and 
improvement  efforts. 

•  The  organization  must  establish  an  organization-wide  training  program  to 
ensure  that  all  practitioners  and  managers  acquire  the  necessary  knowledge 
and  skills  required  to  perform  their  tasks  successfully. 

•  The  organization  must  establish  good  control  of  product  lines,  cost, 
schedule,  and  functionality  and  methodically  track  software  quality  and 
improvement.  These  control  measures  will  help  all  personnel  to  arrive  at 
a  common  understanding  of  processes,  roles,  and  responsibilities. 
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Cost  Estimation  Studies 

In  ^ril  1989,  the  Dlinois  Institute  of  Technology  Research  Institute  (IITRI) 
completed  a  study,  sponsored  1^  the  Ada  Joint  Program  OfBce  (AJPO),  for  ^e  U.S. 
Air  Force  Cost  Center  (AFCSTC)  and  the  U.S.  Army  Cost  and  Economic  Analysis 
Center  (USACEAC).  The  stu^  assessed  the  accura^  of  the  software  cost  models 
for  Ada  software  cost  estimation.  The  six  cost  estimation  models  reviewed  were  as 
follows: 

•  Ada-Specific  Models: 

Ada  COCOMO  (Initial  Operating  Capability) 

SoftCost-Ada 

•  Non-Ada-Spedfic  Models: 

-  PRICES 

-  SYSTEM.3 

-  SPQR/20 

•  Software  Architecture  Sizing  and  Estimating  Tool  (SASET). 

An  essential  part  of  the  research  was  a  test  case  study  in  which  the  costs  models  were 
i^lied  to  a  database  of  eight  conq>leted  Ada  projects.  The  analysis  conq)ared  the 
projections  on  schedule  and  level  of  effort  from  each  model  as  well  as  nominal  run 
results  to  the  actual  project  resources  eiqpended  Ity  the  software  developer.  Results 
for  each  model  were  evaluated  for  accura^  and  consistent  in  each  of  the  following 
categories: 

•  Overall  effort 

•  Overall  schedule 

•  Government  contracts 

•  Commercial  contracts 

•  Command  and  control  applications 

•  Tools  and  environment  applications. 

Model  results  were  also  evaluated  based  on  the  approadi  to  the  project  and  the 
personnel’s  experience  with  Ada.  Interestingly,  no  correlation  was  found  between  the 
performance  of  the  models  and  language  considerations  of  the  models  described  in 
the  study.  The  test  case  study  results  demonstrated  the  benefits  of  using  cost  models 
to  help  Ae  estimator  predia  resource  requirements  for  a  new  development,  but  they 
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did  not  validate  the  need  for  Ada-specific  models.  Although  SoftCost-Ada  was  the 
most  accurate  model  on  all  dimensions,  non-Ada-specific  models  were  comparable 
in  terms  of  accuracy  and  consistency.  Of  greater  interest,  however,  is  that  the  results 
suggest  users  should  consider  the  following  factors  to  determine  which  models  should 
be  applied  to  estimate  Ada  software  costs: 

•  The  amount  of  information  available  about  the  project  and  the  developing 
organization 

•  The  customer 

•  The  type  of  application. 

Before  the  IITRI  study,  the  MITRE  Cost  Analysis  Technical  Center  (CATC) 
conducted  research  to  study  the  "early  returns"  of  developing  software  in  Ada.  The 
research  showed  that  the  productivity  for  first-time  Ada  developments  was  not 
significantly  different  fi'om  that  for  non-Ada  developments.  Constructive  Cost  Model 
(COCOMO)  semidetached  developments,  which  supported  the  early  claims  of 
programming  language  comparability.  This  research  provided  cahbrated  equations 
and  recommended  guidelines  for  estimating  the  costs  and  schedule  for  Ada  projects 
that  are  considered  to  be  organic  and  semidetached  developments. 

Subsequently,  in  1991,  a  follow-on  research  effort  was  initiated  to  expand  the  CATC 
database  of  embedded  Ada  projects,  to  develop  new  models  for  estimating  level  of 
effort  and  duration  of  Ada  developments,  and  to  expand  the  CATCs  knowledge  of 
the  issues  and  cost  impacts  of  programming  in  Ada.  This  research  produced 
improved  parametric  m(^els  and  equations  for  estimating  the  level  of  effort  for  Ada 
software  developments  and  developed  improved  methods  for  quantifying  the  errors 
in  these  models.  The  study  also  developed  appropriate  guidelines  for  estimating 
costs  and  schedules  of  embedded  Ada  developments. 

The  most  significant  finding  of  this  study  was  that  productivity  was  better  on 
embedded  software  developments  where  Ada  was  used  as  the  programming  language 
than  on  developments  where  non-Ada  languages,  such  as  FORTRAN,  JOVIAL,  or 
C+  +,  were  used.  The  calibrated  level-of-effort  models  for  Ada  and  non-Ada  show 
significant  differences  in  their  respective  predictions  of  level  of  effort  for  large 
projects.  Although  this  result  is  based  on  a  limited  data  set,  the  findings  support 
claims  that,  for  large  projects,  Ada  software  is  less  costly  to  develop  than  non-Ada 
software. 
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For  embedded  Ada  developments,  the  following  coefficients  should  be  used  when 
using  the  CX)COMO  equations  for  estimating  software  development  cost  and 
duration: 

SM  =  82  KEDSI 

CM  »  4.8  SM029 

where, 

SM  s  development  effort  in  staff-months 

CM  s  project  duration  in  calendar  months 

KEDSI  =  software  size  in  thousand  of  delivered  source  instructions  (KEDSI 
ranges  from  16  to  415) 

The  linear  form  of  the  level-of-effort  model  for  embedded  Ada  developments 
represents  a  significant  difference  from  traditional  level-of-effort  models  for  non-Ada 
software  developments.  For  large  Ada  projects,  the  non-Ada  level-of-effort  models 
significantly  overestimate  the  development  effort  Although  additional  data  on  large 
Ada  projects  are  needed,  these  findings  strongly  indicate  that  developing  large 
programs  may  be  less  costly  in  Ada  than  in  other  High  Order  Languages  (HOLs). 

The  MITRE  research  also  resulted  in  the  development  of  new  schedule  equations 
that  incorporate  software  size  as  the  independent  variable.  For  embedded  Ada 
developments,  the  following  model  can  be  used  as  an  alternative  method  for 
estimating  software  development  duration: 

CM  «  11.8  KEDSI023 

It  should  be  noted  that  the  above  equations  were  developed  using  a  limited  set  of 
projects  ranging  in  size  from  16  to  415  KEDSI.  The  application  of  these  models  to 
projects  outside  this  range  should  be  avoided. 

For  semidetached  Ada  developments,  the  following  equations  should  be  used  for 
estimating  software  developments  costs  and  duration: 

SM  s  7.4  KEDSI  (KEDSI  ranges  from  2  to  72) 

CM  =  6.0  SM022 
CM  «  103  KEDSI030 
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Again,  the  calibrated  equations  for  semidetached  developments  were  based  on 
projects  spanning  a  softv^e  size  range  from  2  to  72  KEDSI;  therefore,  analysts 
should  exercise  caution  if  using  these  semidetached  equations  for  estunating  outside 
of  this  range. 

It  is  important  to  note  that  the  software  size  inputs  to  the  level-of-effort  models  and 
new  models  for  estimating  schedule  are  based  on  Ada  statements  (terminal 
semicolons)  rather  than  physical  lines  of  code.  For  sizing  purposes,  one  Ada 
statement  can  be  considered  equivalent  to  one  statement  in  other  HOLs  such  as 
FORTRAN  and  JOVIAL.  When  analysts  obtain  sizing  estimates  for  use  in  the 
estimating  models,  care  should  be  taken  to  ensure  that  the  inputs  are  in  Ada 
statements  or  terminal  semicolons  rather  than  in  lines  of  code.  Where  possible, 
analogies  should  be  used  when  specific  project  information  is  available. 

When  little  information  is  known  about  the  project,  or  if  a  quick,  rough  estimate  is 
needed,  productivity  can  be  used  to  estimate  software  development  effort  For  these 
cases,  the  database  of  Ada  projects  indicates  a  productivity  range  of  approximately 
75  to  160  Equivalent  Delivered  Source  Instructions  Per  Staff>Month  (EDSI/SM)  for 
embedded  Ada  and  approximately  110  to  230  EDSI/SM  for  semidetached  Ada. 
When  an  average  productivity  rate  is  used  to  develop  rough  point  estimates  of  effort 
an  average  productivity  of  122  EDSI/SM  is  appropriate  for  embedded  projects, 
whereas  an  average  productivity  of  160  EDSI/SM  is  a^  ropriate  for  semidetached 
projects.  Again,  it  is  strongly  recommended  that  the  database  of  Ada  projects  be 
used  to  develop  an  analogy  when  specific  project  information  is  available. 

In  addition  to  the  software  estimation  models  identified  by  the  li  iKl  and  MITRE 
studies,  several  other  models  are  currently  used  and  recommended  for  use  by 
programs  within  the  Department  of  the  Navy.  The  following  automated  models  are 
popular  among  the  acquisition  and  development  communities  for  forecasting  program 
software  costs  because  of  their  ease  of  use,  reliability,  and  validity: 

•  SASET 

•  Revised  Intermediate  COCOMO  (REVIC) 

•  Software  Evaluation  and  Estimation  of  Resources  (SEERO) 

•  COSTi^ 

•  SEERO  SEM  (Software  Estimation  Model) 

•  SEERO  SSM  (Software  Sizing  Model). 

SEERd  is  a  registered  trademark  of  SEER  Technologies  Division,  Galorath 
Associates,  Incorporated,  Marina  del  Rey,  California. 
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SASET  is  available  upon  request  to  programs  for  their  use.  Also,  SASET  is  being 
modified  to  accommodate  Function  Point  analysis.  The  Navy  Center  for  Cost 
Analysis  (NCA)  can  provide  programs  with  the  points  of  contact  in  the  other  Services 
who  have  other  software  cost  estimating  models,  such  as  REVIC.  The  National 
Aeronautics  and  Space  Administration’s  (NASA’s)  version  of  AdaCOCOMO, 
COSTMODL,  also  is  available;  however,  the  U.S.  Air  Force  point  of  contact  does 
not  give  it  hi^  marks  for  Automated  Information  Systems  (AISs).  Also,  NASA’s 
AdaCOCOMO  is  tuned  for  tactical  applications.  NCA  also  does  the  Independent 
Cost  Estimates  for  Navy  AIS  programs. 
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Appendix  E 

Example  of  Metric  Wording  for  Use  in  a  Contractual 
Document 

Software  Manasonent  Metrics  Requiranents 

The  oontiactor  shall  include  gnq)hs  of  Software  Management  Metrics  (SMM)  in  die 
Software  Developmental  Status  Report  (SDSR).  The  x>axis  of  each  graph  shall  contain 
the  calendar  months  of  the  program  and  shall  depict  the  times  of  System  Requirements 
Review  (SRR),  System  Design  Review  (SDR),  Preliminary  Design  Review  (PDR),  and 
Critical  Design  Review  (CDR).  Should  SMM  data  change  as  SDSRs  are  presented,  the 
contractor  shall  always  show  the  original  esdmate  together  with  the  current  estimate  and 
indicate  the  changes  since  the  last  estimate. 

SMM  data  shall  be  depicted  for  all  software,  regardless  of  whether  the  prime  contractor 
and/or  subcontractors  (if  any)  are  involved  in  the  development  and  wheAer  the  software 
is  newly  developed,  existing,  or  reused. 

The  information  shown  shall  be  as  specified  below. 

1.  Software  Size 

The  contractor  shall  use  an  automated  tool  to  estimate  the  size  of  the  software  that  needs 
to  be  devdoped  and  shall  rqiort  this  estimated  size. 

During  actual  software  development,  the  contractor  shall  rqmrt  the  Source  Lines  of  Code 
(SLCX!))  elements  in  accordance  wiA  the  information-provided  in  the  attachment  to  this 
appendix  (to  be  supplied  by  contracting  organization).  SLOC  metrics  shall  be  provided 
for  each  Conftguration  Item  (Cl)  for  each  programming  language  used.  The  contractor 
shall  utilize  an  automated  Code  Counting  Program  (CCP)  to  provide  the  SLOC  metrics 
results. 

On  a  single  grsqih,  the  contractor  shall  show  the  current  values  of  total,  new,  reused,  and 
modified  SLOC  counts. 

2.  Design  Cmnplexity 

As  software  is  developed,  for  each  programming  language  used,  the  contractor  shall  use 
tile  sqiprqiriate  static  analyzer  of  the  Verilog  Logiscqpe  tool  to  show  flow  gra^s,  call 
graphs,  and  Kiviat  diagrams  for  each  CL 
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3.  Software  Personnel 

The  OHitractor  shall  record  the  number  of  engineering  and  management  personnel 
supporting  software  development  in  experience  cat^ories  of  1  through  3  years,  4  through 
8  years,  and  9  or  more  years.  Software  system  planning,  requirements  definition, 
design,  coding,  testing,  documentation,  configuration  management,  and  Quality 
Assurance  (QA)  personnel  shall  be  included. 

Each  contractor  development  organization  must  provide  graphs  showing  planned  and 
actual  personnel  in  the  various  experience  categories. 

4.  Software  Volatility 

The  contractor  shall  provide  three  different  gr{y)hs  showing  software  volatility  on  the  y- 
axis.  One  griyrh  shall  contain  the  total  number  of  "shall”  statements  (requirements)  in 
the  Software  Requirements  Specifications  (SRSs)  and  the  cumuls^ve  number  of 
requirements  changes  (including  additions,  deletions,  and  modifications).  A  second 
graph  shall  contain  new  and  cumulative  Software  Requirements  Changes  (SRCs),  which 
are  the  number  of  unresolved  requirement  and/or  design  issues.  A  diird  gra^  shall 
depict  Software  Action  Items  (SAIs)  that  have  been  opoi  ftom  1  to  45  days,  46  to  90 
days,  or  over  90  days. 

5.  Computer  Software  Unit  Development  FTt^gress 

The  ccmtractor  shall  graph  the  progress  made  in  Computer  Software  Unit  (CSU) 
devel<pm<mt  against  initi^  plans.  This  progress  shall  be  reported  to  show  monthly 
planned  versus  actual  progress  of  the  number  of  CSUs  designed,  tested,  and  integrated. 

6.  Testing  Progress 

The  contractor  shall  record  and  graph  the  progress  of  Cl  and  system  testing  against  initial 
plans  and  the  degree  to  which  the  software  is  meeting  requirements.  One  graph  shall 
depict  the  number  of  Cl  tests  planned  and  passed,  together  with  the  number  of  system 
tests  planned  and  passed.  A  second  graph  shall  depict  the  number  of  new  Software 
Problem  Reports  (SPRs)  per  month  and  the  SPR  density,  which  is  the  cumulative  number 
of  SPRs  per  1,000  SLOC.  A  third  graph  shall  depict  the  cumulative  number  of  open 
SPRs  and  the  number  of  SPRs  that  have  been  open  ftom  1  through  45  days,  46  through 
90  days,  or  over  90  days. 
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7.  Build  Release  Metric 

The  contractor  shall  present  a  graph  that  contains  each  build,  or  release,  of  the  software, 
showing  the  number  of  originally  planned  versus  currently  planned  CSUs  for  each 
release. 

8.  Computer  Resource  Utilization 

The  contractor  shall  record  the  utilization  of  each  target  computer  resource,  including 
memory  (all  types),  Input/Output  (I/O)  channels,  I/O  bandwidth,  processor  throughput 
under  various  extreme  system  loads,  expected  "nomud”  system  load  (including  I/O),  and 
memory  use  during  processing  times.  Utilization  metrics  shall  ht  proposed  by  the 
contractor  and  approved  by  the  Government.  The  data  shall  show  the  planned  versus 
actual  utilization  for  each  target  computer  resource.  In  addition,  the  crmtractor  shall 
report  on  availability  and  use  of  host  development  station(s)  to  show  planned  versus 
actual  usage. 
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Editor 

The  editor  is  a  tool  for  text  manipulation.  When  conqniters  were  in  their  infancy, 
source  program  text  was  entered  1^  pi^r  tape  or  punned  card.  Today,  editors  are 
sophisticated  interactive  screen/window-management  tools.  Modem  editors  are  used 
not  onfy  for  creating  or  modifying  source  text  but  also  for  viewing  or  modifying  files 
product  by  other  tools. 

An  editor  is  used  primarily  to  aeate  or  modify  source  program  text.  The  product 
of  the  editor  is  a  file  that  contains  the  source  program  statements.  Because  these 
program  files  will  always  have  to  be  con^iled,  the  advantage  was  recognized  of 
having  a  language-specific  editor,  a  tool  with  some  built-in  i^dfic  language 
requirements.  These  editors  simplify  the  entering  of  program  text  and  sometimes 
perform  on-line  error  checking. 

In  its  most  elementaiy  form,  a  language-specific  editor  may  have  special  options  to 
assist  in  formatting  the  source  text  An  example  for  FORTOAN  would  be 
automatically  starting  a  line  in  column  7  whenever  the  first  character  was  alphabetic, 
thus  preventing  text  from  being  placed  in  the  field  reserved  for  line  numbers. 

Another  form  of  a  language-specific  editor  is  the  "^tax-directed  editor,"  which  is 
tightly  linked  to  the  programming  language.  Most  modem  languages  require  opening 
and  dosing  statements  for  stractured  programming  constructs.  A  ^tax-directed 
editor  can  provide  templates  for  these  constmcts.  For  example,  the  following 
tenq)late  could  be  rapidly  placed  on  the  screen  after  ^ing  "if: 

if  <condition> 
then 

else 


endif; 
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In  addition,  the  ^tax*directed  editor  can  check  the  structure  of  the  source  text  for 
compliance  with  the  rules  of  the  language.  Thus,  the  efficiency  of  the 
edit-compilation  process  is  improved  because  many  programming  errors  are 
eliminated  before  compilation. 

Compiler 

A  compiler  is  a  program  that  translates  a  High  Order  Language  (HOL)  source 
program  into  its  relocatable  code  equivalent  The  term  "host"  refers  to  the  computer 
that  translates  the  source  program,  and  the  term  "target”  refers  to  the  computer  that 
will  execute  the  compiled  code.  The  term  "cross-compiler"  refers  to  the  case  in  vhidi 
the  target  computer  is  different  from  the  host  computer.  In  many  DON  applications, 
a  source  program  is  cross-compiled  on  a  host  computer  (generally  a  commercial 
machine)  for  a  militarized  target  computer  that  is  embedded  in  a  system. 

Compilers  are  usually  multiple  pass  programs  that  may  process  the  source  program 
or  some  intermediate  form  several  times  before  completion.  The  output  of  the 
earlier  stages  is  referred  to  as  intermediate  code.  In  some  host  computer  systems, 
the  intermediate  code  is  used  by  other  tools. 

Compilers  for  real-time  applications  must  produce  code  to  fit  in  limited  storage 
space.  In  addition,  the  execution  speed  on  the  target  computer  must  allow  all  of  the 
required  functions  to  be  computed  in  the  assigned  time. 

Assembler 

An  assembler  is  a  program  that  translates  an  Assembly  source  program  into 
relocatable  code.  Note  that,  usually,  a  one-to-one  correspondence  exists  between  an 
Assembly  source  statement  and  a  machine  instruction.  Assemblers  allow  the 
programmer  to  use  relative  addressing  and  then  specify  a  starting  location  rather 
than  having  to  specify  each  address  in  absolute  terms.  Most  assemblers  also  allow 
the  use  of  labels  and  other  defined  values  and  locations. 

Assembly  has  been  used  frequently  in  Mission-Critical  Computer  Resources  (MCCR) 
applications  because  it  allows  the  programmer  to  optimize  storage  space  and 
execution  time.  However,  Assembly  programs  are  difficult  to  test  and  expensive  to 
maintain.  Today,  the  use  of  Assembly  is  generally  restricted  to  routines  with 
raceptionally  high  performance  requirements  and  to  hardware-diagnostic  software. 


Linker 

Source  program  modules,  whether  in  Assembly  or  a  HOL,  usually  are  translated 
separately  into  modules  of  relocatable  code.  Once  translated,  the  modules  must  be 


F-2 


Department  of  the  Navy 


SofhwaraTool  DMcriptiom 


.  iked  together  before  execution.  A  linker  is  a  program  that  creates  a  load  module 
from  one  or  more  independently  translated  modules  by  resolving  the  cross-references 
among  the  modules. 

Relocating  Loader 

Relocatable  code  contains  relative  addresses  of  machine  instructions  and  data.  This 
defers  the  assignment  of  absolute  addresses  until  the  program  is  ready  for  execution 
and  allows  the  flexibility  of  placing  the  program  in  any  contiguous  block  of  storage. 
The  linker  creates  a  load  module  that  leaves  all  addresses  in  relative  form  although 
it  has  resolved  the  cross-references  between  modules.  The  relocating  loader  is  a 
program  that  executes  on  the  host  computer  and  translates  the  relative  addresses  into 
the  absolute  addresses;  its  output  is  an  execution  module.  A  bootstrap  loader 
executes  on  the  target  computer  and  copies  the  execution  module  into  its  storage. 

Rnn-Time  Environment 

The  Run-Time  Environment  (RTE)  resides  on  the  target  machine  and  provides  a 
variety  of  services  for  application  programs.  Typical  RTE  functions  are  dynamic 
storage  management,  exception  processing,  input  and  output,  and  task  scheduling. 
Because  this  environment  is  used  for  all  application  programs,  it  should  be  small  and 
fast  to  minimize  the  overhead.  The  RTE  usually  is  modularized  according  to  the 
particular  services  it  provides  and  is  automatically  configured  when  the  execution 
module  is  created.  Thus,  if  an  application  program  does  not  need  a  particular 
service,  that  module  is  automatically  omitted  from  the  RTE. 

Simulator/Emulator 

When  code  is  produced  for  a  target  computer  that  is  different  from  the  host,  the 
problem  of  how  to  test  the  code  must  be  considered.  Testing  on  the  target  computer 
is  usually  difficult  because  the  computer  may  still  be  under  development,  it  may  be 
being  integrated  with  other  embedded  subsystems,  or  the  number  of  target  machines 
may  be  insufficient  to  support  all  of  the  programmers.  Moreover,  most  embedded 
target  computers  have  poor  tools  to  support  testing. 

One  solution  to  this  problem  is  to  build  a  software  simulator  or  emulator  of  the 
target  computer  that  executes  on  the  host  computer.  A  software  emulator  accepts 
the  same  data,  executes  the  same  instructions,  and  achieves  the  same  results  as  the 
target  machine.  A  simulator  imitates  selected  features  of  the  target  computer  but 
is  not  required  to  achieve  identical  results.  The  best  tool  is  a  target  computer 
emulator  that  can  operate  in  either  batch  or  interactive  mode.  The  execution  speed 
of  an  emulator  may  be  significantly  slower  than  that  of  the  target  computer,  but  the 
emulator  has  many  advantages.  For  example,  the  emulator  can  be  time  shared  and 
used  by  everyone  on  the  host  computer.  In  addition,  because  the  emulator  is  on  the 
h(»t  computer,  it  is  easy  to  generate  test  data,  load  the  module  and  test  data  into  the 
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emulator,  and  monitor  the  test  while  in  progress.  Long  tests  can  be  run  in  batch 
mode  during  off-peak  hours. 

In-Circuit  Emulator 

An  in-cucuit  emulator  provides  the  user  with  a  means  of  executing  a  software 
program  located  in  external  Random  Access  Memory  (RAM)  rather  than  internal 
Read  Only  Memory  (ROM)  or  Erasable  Programo^le  Read  Only  Memory 
(EPROM).  This  allows  easy  and  ra^id  modification  of  the  programs  being  debugged 
during  the  testing  cyde.  When  cormeaed  to  the  prototype  system  through  the 
microprocessor  socket,  an  in-circuit  emulator  can  emulate,  test,  and  trace  the 
prototype  system  operation.  The  internal  state  of  the  microprocessor,  including 
RAM,  accumulator,  internal  working  registers,  and  stack  and  status  registers,  can  be 
observed  and  modified.  Some  in-drcuit  emulators  allow  the  recording  of  data  bus 
operations.  This  feature  allows  the  engineer  to  capture  N  events  before  or  after  a 
f^ure  or  predefined  occurrence. 

Symbolic  Debugger 

A  symbolic  debugger  allows  a  programmer  to  test  a  module  by  controlling  the 
program  execution  on  a  target  computer  emulator  or  the  target  computer  itself. 
With  the  symbolic  debugger,  the  programmer  can  address  the  variables  using  their 
source  program  symbols  or  names.  The  facilities  usually  provided  include  stopping 
execution  at  selected  locations,  moving  by  single  steps  in  increments  of  source 
statements,  watching  the  value  of  specified  variables,  tracing  execution,  examining  the 
contents  of  variables,  evaluating  expressions,  displaying  the  current  sequence  of 
routine  calls,  displaying  the  source  corresponding  to  any  part  of  the  program, 
executing  debug  command  procedures  at  break  points,  and  calling  procedures  that 
are  program  parts. 

Pretty  Printer 

A  pretty  printer  is  a  program  that  automatically  applies  standard  rules  for  formatting 
program  source  code.  It  will  accept  an  input  file  and  format  the  text  to  match  a  style 
guide.  For  example,  a  pretty  printer  for  a  block-structured  language  will  produce  a 
listing  in  which  the  indentation  level  of  each  blodc  shows  its  nesting  level.  A  pretty 
printer  helps  the  programmer  read  and  comprehend  the  program.  After  extensive 
program  modifications,  for  example,  it  helps  eliminate  confusion  about  the  program 
structure  and  nesting  levek. 

Host-to-Target  Exporter 

If  the  target  machine  is  different  fi’om  the  host  machine,  it  is  necessary  to  have  a  tool 
to  transmit  the  execution  module  from  the  host  to  the  target  Standard 
communications  software  and  hardware  may  be  used,  but  these  are  rarely  available 
for  embedded  machines. 
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It  is  desirable  to  have  a  flexible,  high-bandwidth  communications  link  between  the 
host  and  target.  If  the  link  has  a  "pass-through”  capability,  then  an  interactive  user 
of  the  host  computer  can  run  tests  on  the  embedded  computer  from  the  same 
terminal.  High  bandwidth  is  desirable  because  large  volumes  of  data  must  be 
exchanged  between  the  host  and  target;  for  example,  diagnostic  software  is  typically 
sent  to  the  target  to  test  the  target  hardware,  and  test  data  and  test  results  are  also 
exdianged.  A  high-bandwidth  communications  link  will  reduce  the  time  it  takes  to 
do  these  tasks  and  allow  more  time  for  testing. 

Computer-Aided  Software  En^neerlng 

Computer-Aided  Software  Engineering  (CASE)  refers  to  software  tools  that  help 
automate  parts  of  the  software  process  across  the  life  cycle.  These  tools  are 
considered  a  part  of  a  Project  Support  Environment  (PSE).  CASE  tools  support  the 
activities  associated  with  a  specific  part  of  the  system  software  life  cycle,  such  as 
requirements  specification,  coding,  and  testing.  CASE  tools  also  can  support  project 
management  activities  across  the  life  cycle.  Recently,  many  tools  have  emerged  that 
support  software  requirements  specification  and  hi^-level  design.  CASE  tools  can 
help  users  organize,  document,  and  generate  a  specification.  Some  of  the  more 
ath^ced  tools  also  can  execute  simulations  of  the  specification  and,  to  a  certain 
degree,  generate  Ada  code  or  code  fragments  that  fulfill  the  developed  requirements 
and  design.  Although  many  CASE  tools  will  examine  the  specification  and  hi^-level 
design  for  consistency  and  completeness,  current  CASE  tools  have  widely  varying 
degrees  of  functionality  and  maturity.  Tbe  future  of  CASE  tools  is  bright  and  the 
potential  benefits  great  Many  tools  are  immature,  however,  and  contractors'  claims 
regarding  the  capabilities  of  their  tools  are  often  exaggerated.  Some  CASE  tools 
have  difficulty  scaling-up  to  support  large  software  developments  (e.g.,  more  than 
100,000  Source  lines  of  Code  [SLOC]).  Finally,  few  CASE  tools  are  compatible  with 
each  other  with  regard  to  method  of  data  transfer  or  integrated  execution. 

Many  CASE  issues  are  similar  to  issues  surrounding  the  introduction  of  Ada.  CASE 
will  help  impose  discipline  on  the  software  process,  provide  better  visibility  into  the 
software,  and  encourage  the  use  of  modem  methods  and  practices.  Three  primary 
benefits  of  using  CASE  on  a  project  are  improved  product  documentation,  improved 
project  communication,  and  eitforcement  of  a  consistent  design  and  requirements 
methodology. 

Many  of  the  issues  surrounding  the  adoption  and  use  of  CASE  are  organizational, 
not  technical,  issues.  The  organization  must  have  a  well-defined  software  engineering 
methodology  in  place  before  the  benefits  of  CASE  tools  can  be  realized.  Use  of 
CASE  tools  often  requires  a  pervasive  change  in  an  organization.  First,  an  absolute 
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and  strong  management  support  of  and  commitment  to  CASE  use  are  needed. 
Second,  selection  of  high-quality  personnel  and  extensive  training  are  necessary. 
Third,  the  resistance  to  change  must  be  overcome. 

In  some  cases,  the  initial  adoption  of  CASE  requires  a  large  csqiital  investment  and, 
most  likely,  schedule  expansioiL  This  up-front  cost  in  terms  of  dollars  and  schedule 
will  be  recovered  when  the  lower  maintenance  costs  are  realized. 

CASE  tools  are  emerging  on  the  market  that  maintain  the  specification  at  a  high 
level  and  automatically  generate  Ada  code.  The  intent  is  to  make  all  changes  at  the 
specification  level  and  not  at  the  code  level.  This  technology  promises  to  provide 
maity  benefits  to  software  engineering.  CASE  will  surely  have  an  increasing  impact 
on  programs  developed  in  Ada  and  the  Ada  software  development  environment 
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This  iqppendix  identifies  current  and  emerging  standards  associated  with  the  service 
areas  addressed  in  the  National  Institute  of  Science  and  Tedmology  (NIST) 
.^iplication  Portablility  Profile  (APP)  and  DOD  Technical  Architecture  Framework 
for  Information  Management  (TAFI^. 

G.1  OPERATING  SYSTEM  SERVICES 

The  following  subsections  discuss  some  recommended  operating  system  services. 
G.1.1  Kernel  Operations  API 

FIPS  PUB  151-2  Portable  Operating  System  Interface  (POSIX)—Sy^\e,m  ^plication 
Programming  Interface  (API).  Kernel  operations  provide  low-level  services  necessary 
to  create  and  manage  processes,  execute  programs,  define  and  communicate  signals, 
define  and  process  ^tem  dock  operations,  manage  files  and  directories,  and  control 
Input/Output  (I/O)  processing  to  and  from  external  devices. 

G.L2  Operating  ^stem  Commands  and  Utilities  API 

Planned  FIPS  PUB  on  POSDC—Pzrt  2.  Commands  and  utilities  indude  mechanisms 
for  operations  at  the  operator  level,  such  as  comparing,  printing,  and  displaying  file 
contents;  editing  files;  pattern  searching;  evaluating  erqrressions;  logging  messages; 
moving  files  between  directories;  sorting  data;  executing  command  scripts;  scheduling 
signal  execution  processes;  and  accessing  environment  informatioiL 

G.U  Operating  System  Real-time  Services  API 

Amendment  1:  Realtime  Extension  PI003.4  Draft  12.  This  document  provides  the 
operating  system  extensions  needed  to  allow  incorporation  of  real-time  application 
domains  into  the  Open  Systems  Environment  (OSE).  The  extensions  define  the 
application’s  interface  to  basic  system  services  for  I/O,  file  system  access,  and  process 
management 

G.1.4  Operating  System  Security  API 

Secur^  Interface  for  POSDC  (IEEE  P1003.6  Dnft  II).  Security  considerations  are 
specified  in  terms  of  data  encryption  mechanism,  access  control,  reliability  control, 
^tem  logging,  fault  tolerance,  and  audit  facilities. 

G2  HUMAN-COMPUTER  INTERFACE  SERVICES 

The  following  subsections  discuss  the  recommended  Human-Computer  Interface 
(HQ)  services. 
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GJ2.1  Graphical  User  Interface  API 

Proposed  FIPS  PUB  User  Interface  Component  of  the  APP  (MIT  XWindow  Syaem). 
The  MIT  XWindow  System  is  the  Federal  standard  for  Graphical  User  Interfaces 
(GUIs)  in  the  OSE.  Its  software  has  proven  to  be  highly  portable  between  various 
hardwve  platforms  and  operating  systems.  Because  of  its  client>server  architecture, 
the  X  client  application  can  run  on  one  system  while  the  X  server  can  be  running  on 
another  ^tem  on  a  network. 

G22  Graphical  User  Interface  Toolkit  API 

Drtft  Standard  for  Information  Technology— XWbtdow  System  Graphical  User 
Int^ace—Part  1:  Modular  Toolkit  Environment  (IEEE  P1295J).  This  specification 
supports  writing  portable  applications  with  GUIs  based  on  the  XWindow  System.  It 
defines  a  source-code-level  interface  to  an  XWindow  System  toolkit  GUI 
environment  based  on  the  OSF  Motif  ^plication  Environment  Specification  User 
Environment  volume. 

G3  SOFTWARE  ENGINEERING  SERVICES 

The  following  subsections  discuss  certain  recommended  software  engineering  services. 
GJ.1  Programming  Language  Ada 

FIPS  PUB  119  Ada.  Ada  is  a  general-purpose,  high-level  programming  language. 
In  addition,  it  provides  strong  data-typing,  concurrence,  and  significant 
code-structuring  capabilities.  It  is  particularly  suited  to  embedded  real-time  ^tems, 
distributed  ^tems,  highly  reliable  software  development,  and  reuse  of  proven  code. 

G3.2  Integrated  Software  Engineering  Environment 

Portable  Common  Tools  Environment  (PCTE):  Abstract  Specification,  Standard 
ECMA-149,  European  Computer  Manufacturing  Association  (ECMA).  Integrated 
Software  Bigineering  Environments  (ISEEs)  and  tools  include  systems  and  programs 
that  assist  in  the  automated  development  and  maintenance  of  software.  These 
include,  but  are  not  limited  to,  tools  for  requirements  specifications  and  analysis,  for 
design  work  and  analysis,  for  creating  and  testing  program  code,  for  documenting,  for 
prototyping,  and  for  group  communication.  The  interfaces  among  these  tools  include 
services  for  storing  and  retrieving  information  about  systems  and  exchanging  this 
information  among  the  various  programs  in  the  development  environment  PCTE 
can  provide  for  this  data  repository  functionality. 

G  Other  Programming  Languages 

See  the  NIST  APP  for  FIP-PUBs  on  Other  Programming  Languages. 
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DATA  MANAGEMENT  SERVICES 

The  following  subsections  discuss  certain  reconunended  data  management  services. 

GAl  Relational  Database  Management  ^rstem  Interface 
Planned  FIPS  PUB  127'2  Database  iMngLUigeStmcaindQiieryLanffuige  (SQL).  FIPS 
SQL  provides  data  management  services  for  definition,  query,  update,  administration, 
and  security  of  structured  data  stored  in  a  relational  database.  A  relational  database 
is  appropriate  for  general-purpose  data  management,  especially  applications  requiring 
flexibility  in  data  structures  and  access  paths;  it  is  particularty  desirable  where  there 
is  a  substantial  need  for  ad  hoc  data  manipulation  for  data  restructuring.  The 
security  interface  for  granting  and  revoking  privileges  does  not  specify  a  secure 
DBMS;  only  its  interface. 

G,4J  Data  Dictionary  or  Directory  System 

FIPS  PUB  156  Infonnation  Rescnace  Dictionary  System  (IRDS).  Data  dictionary  or 
directory  services  consist  of  utilities  and  ^tems  necessary  to  catalog,  document, 
manage,  and  use  metadata  (information  about  data). 

G.43  Distributed  Data  Access 

Remote  Database  Access  (RDA)  ISO/IEC  9579:2993.  RDA  is  used  to  establish  a 
remote  coimection  between  an  RDA  client,  acting  on  behalf  of  an  application 
program  or  a  client  data  manager,  and  an  RDA  server,  interfacmg  to  a  process  that 
controls  data  transfers  to  and  from  a  database.  The  goal  is  to  promote  the 
intercormection  of  applications  and  the  interoperability  of  Database  Management 
Systems  (DBMSs)  among  heterogeneous  enviromnents. 

G  J  DATA  INTERCHANGE  SERVICES 

The  following  subsections  discuss  certain  recommended  data  interchange  services. 
G^.l  Data  Interchange 

Open  Document  Architecture  (ODA)/Open  Document  Interchange  Format  (ODIF)/ 
Open  Document  Language  (ODL)  [ODA/ODIF/ODL]  ISO  8613:1989.  ODA  is  a 
framework  that  enables  users  to  interchange  the  logical  structure,  content, 
presentation  style,  and  layout  structure  of  documents  from  one  sqrplication  to 
ar^other.  ODIF  is  an  encoding  scheme  for  documents  suitable  for  interchange 
betv/een  applications.  ODL  is  a  generic  Standard  Generalized  Markup  Language 
(SGML)  encoding  for  ODA  documents  to  enter  an  SGML  database  or  publishing 
envirorunent 
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GS2  Documoit  Interchange 

FJPS  PUB  152  Standard  Generalized  Mtakup  Language  (SGML).  SGML  is  a 
generalized  grammar  used  to  write  data  type  definitions  for  describing  document 
types  and  styles. 

G  Page  Description  Language 

Planned  PIPS  for  Standard  Page  Description  Language  (SPDL)  ISO/IEC  DIS 10180. 
SPDL  defines  a  language  for  representing  images  that  are  to  be  di^layed  on  a 
screen,  printed  on  an  output  device,  or  transmitted  through  communications  media 
from  one  application  to  another. 

G^.4  Manuscript  Markup  Interchange 

Electnmic  Manuscript  Preparation  and  Markup  (EMPM)  American  National  Standards 
Institute/Natiorud  Information  Standards  Orgcavzation  (ANSI)/(NISO)  Z39.59-1988. 
EMPM  is  a  specialized  document  type  de^tion  that  includes  an 
architecture-encoded  SGML  suitable  for  the  interdiange  of  the  logical  structure  of 
books,  articles,  and  serials. 

G^  Graphics  Data  Interchange 

Computer  Graphics  Metafile  (CGM),  PIPS  PUB  128.  Graphics  data  are  specified  in 
terms  of  a  file  format  that  can  be  aeated  independently  of  device  requirements  and 
translated  into  the  formats  needed  by  specific  ouq>ut  devices,  gnqphic  tystems,  and 
conqiuter  systems. 

G,5.6  Graphic  Product  Data  Interchange 

PIPS  PUB  1 T7  Initial  Graphics  Exchange  Sp&dfication  (IGES).  IGES  standardizes  the 
representation  of  specific  types  of  complex  grsqjhic  objects  and  attributes  for  data 
interdumge.  Information  typically  associated  with  computer-aided  design  and 
manufacturing  (CAD/CAM)  can  be  described. 

GSJ  Product  life  Cycle  Data  Interchange 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP)  Draft  Proposed  ISO  10303. 
STEP  is  an  advanced  form  of  representing  complex  data  objects  for  interchange.  It 
is  used  in  total  life  ^de  descriptions  of  engineered  products  that  can  be 
implemented  on  advanc^  manufricturii^  systems.  This  indudes  specifications  of 
pr^ucts  throughout  the  stages  of  their  lifetimes. 

G^^  Electronic  Data  Interchange 

PIPS  PUB  161  Electrortic  Data  Interchange  (EDI).  EDI  is  a  procedure  in  whidi 
instances  of  documents  to  be  interchanged  between  separate  organizations  are 
converted  to  strictly  formatted  sequences  of  data  elements  and  transmitted  as 
messages  between  computers. 

G— 4  Department  of  the  Navy 


Applieatlon  PortabHIty  Prom*  (APP)  8«r«ieM 


GJS3  Spatial  Data  Interchange 

FIPS  PUB  173  Spatial  Date  ransfer  Standard  (SDTS).  This  standard  is  mandatoiy 
in  the  acquisition  and  de-  .  .opment  of  Government  applications  and  prognuns 
involving  the  transfer  of  digi'.al  spatial  data  among  heterogeneous  computer  systems. 

G.6  GRAPHICS  SERVICES 

The  followint  subsections  discuss  selected  recommended  graphics  services. 

G^l  IVpo-Dimensional  Graphics  API 

FIPS  PUB  120-1  Gra/Mcal  Kemd  System  (CIS).  GKS  fulfills  the  requirement  for 
a  language  to  program  two-dimensional  graphical  objects  that  will  be  displayed  or 
plotted  on  appropriate  devices  (raster  grapldcs  and  vector  graphics  devices). 

G.U  Interactive  and  Three-Dimensional  Graphics  API 

FIPS  PUB  153  ProgrammePs  Hierarchical  Interactive  Graphics  System  (PHIGS). 
PHIGS  fulfills  the  requirements  for  a  language  to  program  two-dimensional  and 
three-dimensional  graphical  objects  that  will  be  displayed  or  plotted  on  appropriate 
devices  in  interactive,  Ugh-performance  environments,  and  for  managing  hierarchical 
database  structures  containing  graphics  data. 

G.7  NETWORK  SERVICES 

The  following  subsections  discuss  certain  recommended  network  services. 

G.7.1  Communication  API  for  Protocol  Independent  Interfoces 
Protocol  Independent  Interfaces  (PIIs)  IEEE  P1003.12,  Drttfi  2.0.  PIl  defines  the 
protocol-independent  application  interfaces  to  enable  one  process  to  communicate 
with  another  local  process  or  a  remote  process  over  a  network. 

G.7Jt  Communication  API  for  OSI  Sertices 

Open  Sterns  Iraerconnection  (OSI)  Association  Control  Service  Element 
(ACSE)/Presentation  Application  Program  Interfaces  IEEE  P1238.  OSI  ACSE 
provides  an  API  between  applications  and  the  OSI  and  presentation  services. 

G.7J  File  Ikansfer  API 

OSI  API  for  File  Transfer,  Access,  and  Maruigement  (FTAM)  IEEE  P1238.1.  FTAM 
is  designed  for  use  as  a  standard  application  interface  for  file  transfer,  access,  and 
management  applications. 

G.7.4  Communications  Protocols  for  OSI 

FIPS  PUB  146-1  Government  Open  System  Iraerconnection  Profile  (GOSIP)  Version 
2.  GOSIP  protocols  provide  interoperability  among  applications  in  a  heterogeneous 
network.  GOSIP  is  based  on  the  Open  Systems  Interconnection  (OSI)  standards,  the 


Ada  Implmnantation  Guide 


G-S 


AppHetUon  Portability  Pr^Ho  (APP)  Sarvicaa 

worldwide  consensus  standards  for  multivendor  data  conununications  based  on  OSI 
protocols. 

G.7  J  Communication  API  for  Integrated  Dii^tal,  Video»  and  Voice 
AppUcatUm  Software  Interface  (ASI)  Version  1  for  accessing  and  administering 
Integrated  Servkes  Digital  Network  (ISDN)  services.  ASI  focuses  on  the  definition  of 
a  common  iq[)plication  interface  for  accessing  and  administering  ISDN  services 
provided  by  hmdware  commonly  referred  to  in  the  vendor  community  as  Network 
Adaptors  ^As). 

GJjS  Communication  API  for  Integrated  Dii^tal,  Video,  and  Voice 
NIST  Planned  FIPS  on  Integrated  Services  DigUed  Netw^  (ISDN).  The  proposed 
FIPS  PUB  compiles  the  existing  North  American  ISDN  User’s  Forum  (NIUF) 
agreements  for  ISDN  as  developed  and  approved  in  the  NIUF  as  of  November  1990. 

G.7.7  Remote  Procedure  Call 

OSF  Distributed  Computing  Environment  (DCE)  Remote  Procedure  Call  (RPC) 
Componaa.  Distributed  confuting  services  include  specifications  for  remote 
procedure  calls  and  distributed  real-time  support  in  heterogeneous  networks. 

G.7^  l^sparent  Networic  Access  to  Remote  Files 

Transparent  File  Access  (TFA)  IEEE  P1003.8,  Dnfi  7.  TPA  includes  capabilities  for 
nianaging  files  and  transmitting  data  through  heterogeneous  networks  in  a  manner 
that  is  transparent  (i.e.,  does  not  require  knowledge  of  file  location  or  of  certain 
access  requirements)  to  the  user. 

G,13  Netwoih  Management 

FIPS  PUB  179  Government  Network  Marutgement  Profile  (CNMP),  Version  1.0.  The 
GNMP  is  the  standard  reference  for  all  Federal  Government  agencies  to  use  when 
acquiring  Network  Management  (NM)  functions  and  services  for  computer  and 
communications  systems  and  networks. 

G.7.10  Electronic  Messaging  API 

X.400-Based  Electronic  Messaging  AppUcatUm  Program  Interface  (API)  IEEE  P1224.1, 
Drt0  3.  X.4(X)  provides  electronic  mail  interoperability  among  heterogeneous 
computer  systems.  X.400  is  an  international  standard  protocol  definition.  This  API 
defines  an  interface  between  the  user  of  a  mail  tystem  and  the  mail  tystem. 
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G.7.11  Directoiy  Services  API 

Directmy  Services  Application  Program  Interface  (API)  X.500  IEEE  P1224.2.  X^OO 
provides  the  interoperability  of  dictionaiy  services  among  heterogeneous  computer 
tystems.  The  Directoiy  Services  (DS)  API  defines  a  standard  directoiy  service  user 
agent  interface  to  support  application  portability  at  the  source-code  level 

SECURITY  SERVICES 

No  specifications  are  defined  to  support  security  services. 

G^  MANAGEMENT  SERVICES 

No  specifications  are  defined  to  support  management  services. 

G.10  NIST  APP  SPECinCATTONS  EVALUATIONS 

The  NIST  APP  evaluates  recommended  Reifications  for  each  of  the  APP  services 
and  summarizes  some  of  the  pros  and  cons  of  selecting  each  spedfication.  The 
information  is  provided  to  managers,  tedmical  project  leaders,  and  users  to  assist 
them  in  evaluating  these  specifications  for  inclusion  in  application  or  oiganizational 
profiles.  Each  specification  is  evaluated  according  to  how  well  it  meets  the 
requirements  of  a  specific  criterion.  The  criteria  are  Level  Of  Consensus  (LOC), 
Product  AVailabflity  (PAV),  CoMPleteness  (CMP),  MATurity  (MAT),  STaBility 
(STB),  De  Facto  Usage  (DFU),  and  PRoblems/Liidtations  (PRL).  Definitions  of 
Aese  criteria  are  provided  in  the  NIST  APP.  Table  G-1  presents  the  evaluations  for 
selected  specifications. 
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Appendix  I 

Lessons  Learned 

Ifistorically,  the  Department  of  Defense  (DOD)  has  failed  to  take  advantage  of  past 
eiqieriences  in  develq)ing  software  systems.  The  process  of  reviewing  past  experiences 
and  formulating  new  decisions  based  (M  these  experiences  should  be  ongoing.  It  must 
start  from  the  b^inning  of  the  process  and  continue  through  development  and  into 
dq^loyment  The  software  process  also  should  be  adjusted  for  overall  system  size, 
technical  complexity,  and  de^opment  phase. 

This  ^rpendix  describes  decisions  and  evaluations  made  about  software  ^stmn 
devdt^ments  that  have  led  to  lessons  learned  by  the  users  of  Ada  in  the  commercial  and 
Government  sectors.  Figure  M  presents  a  matrix  of  the  lessons  learned  by  project  in 
the  following  areas: 

•  Standards  and  policy 

•  Project  management 

•  Development  process 

•  Corporate  knowledge  and  software  d^dopment 

•  Training 

•  Resources  and  facilities 

•  Support  environment  and  tools 

•  Reuse 

•  Project  costs. 

In  some  cases,  the  information  presented  in  the  project  descriptions  came  from  internally 
devdoped  evaluations;  in  others,  the  information  is  based  on  externally  develq)ed 
assessments.  Note  that,  except  for  editorial  changes,  the  descriptions  are  reproduced 
here  as  submitted  by  the  originators. 

As  the  examples  show,  different  projects  often  e}q)erienced  similar  problems  and  applied 
similar  rem^es.  Frequently,  a  series  of  non-software>related  errors  culminated  in  the 
production  of  the  wrong  set  of  software  components.  The  lessons  learned  from  these  and 
other  project  experiences  may  help  managers  of  new  projects  to  avoid  such  problems. 
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Figure  M.  Lessoos  Leamed  Matrix 
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Figure  I-l.  Lessoos  Learned  Matrix 
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Figure  M.  Lessons  Learned  Matrix 
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Figure  M.  Lessoos  Learned  Matrix 
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Figure  M.  Lessons  Learned  Matrix 
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Lessons  Lesmed 


1.1  STRATCOM-COMPUTER  CENTER,  OFFUTT  AIR  FORCE  BASE 
STRATCOM— Computer  Center  has  been  using  Ada  since  1989  in  many  programs  and 
projects.  The  center  has  built  small  systems  (3,000  lines  of  code)  and  some  medium 
systems  (over  50,000  lines  of  code).  Lessons  learned  from  this  work,  which  is  mainly 
in  intelligent  databases,  are  described  below. 

Lesson  1:  Visualize  Ada  as  supporting  an  engineering  approach  to  software. 

Lesson  2:  Do  not  anticipate  that  use  of  Ada  mil  decrease  development  time,  particularly 
on  the  first  few  projects. 

Lesson  3:  Try  to  limit  the  number  of  variables  in  the  development  process  (e.g.,  beta 
copies  ofsqftmre,  new  tools)  on  the  first  project.  Using  too  many  variables  will  make 
it  difficult  to  trace  problems. 

Lesson  4:  Do  not  blame  all  problems  on  the  software  or  Ada.  Ada  will  often  be  blamed 
for  anything  and  everything  (whether  it  deserves  the  blame  or  not).  Management  often 
attributes  to  Ada  other  problems  encountered  in  the  use  of  Graphical  User  Interfaces 
(GUIs)  or  Database  Management  Systems  (DBMSs). 

Lesson  5:  Select  a  small  doable  project  for  the  first  Ada  effort. 

Lesson  6:  Use  tools.  The  days  of  the  ”all-I>need-is-a-<ompiler”  are  over.  Software 
engineering  is  a  complicated  business.  Tools  can  be  a  "force  multiplier”  that  helps  the 
engineer  boost  productivity,  establish  consistency  across  software  modules,  and  enhance 
understanding.  Use  of  flowcharts  is  no  longer  sufficient. 

Lesson  7:  Ensure  that  management  understands  that  tools  support  software  engineering, 
not  programming.  Management  should  move  from  managing  just  programmers  to 
helping  engineers  engineer  software  solutions. 

Lesson  8:  Ensure  that  management  focuses  on  the  engineering  aspects  of  Ada,  not  on 
Ada  as  a  programming  language.  As  a  language,  Ada  appears  to  be  complicated,  but 
Ada’s  intricacies  support  sound  software  engineering  principles.  Viewed  in  isolation, 
Ada  is  often  seen  as  overwhelming.  In  the  perspective  of  large  systems  software 
development,  however,  the  features  of  the  language  take  on  a  much  more  valuable 
meaning. 

Lesson  9:  Use  a  well-defined,  repeatable  process  and  methods  for  developing  and 
maintaining  software. 
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Lesson  10:  Implement  an  active  training  program  in  both  Ada  and  software  engineering. 

Lesson  11:  Ensure  that  adequate  resources  (e.g.,  hardware  capadty,  didt  space,  tools) 
are  available. 

Lesson  12:  Have  adequate  corftguration  management.  A  well-structured  approadi  to 
devdq)inent  of  a  large  project  will  require  several  program  units,  especially  in  an  object- 
oriented  environment.  Proper  management  of  these  units  is  crucial  when  a  multiperson 
team  is  updating  the  modules. 

Lesson  13:  Assess  software  engineering  capabilities  before  the  projea  gets  under  way. 
Management  should  know  what  the  oiganization’s  weaknesses  are  and  how  they  will 
affect  an  intense  Ada  or  software  engineering  project. 

Lesson  14:  Do  not  expect  to  transform  mairuenance  personnel  into  developers  overnight. 

Lesson  IS:  Do  not  field  products  before  they  are  ready.  Management  tends  to  scrutinize 
Ada  projects  more  closely  than  other  projects  (pertiaps  because  it  expects  them  to  fail). 
This  scrutiny  often  leads  to  delivering  products  before  they  are  fully  tested. 

Lesson  16:  Tailor  the  Data  Item  Descriptions  (DJDs)  from  Military  Standard  (MIL- 
STD)-2167A. 

Lesson  17:  Do  not  neglea  documeruation.  Well-written  Ada  is  a  must,  but  the  code  is 
not  totally  self-documenting.  Requirements,  design,  and  other  life-cycle  management 
documents  also  are  needed  to  give  the  total  development  incture.  You  must  provide  a 
vdiicle  to  update  documentation  (e.g.,  flowcharts,  data  flow  diagrams)  that  is  detached 
from  the  code  as  the  code  changes. 

lesson  18:  Use  Commercial-Off'-The-Shelf  (COTS)  products  as  well  as  reuse 
repositories,  where  available.  Bindings  to  existing  software  products  should  be  written, 
tested,  and  then  reused.  Avoid  reinventing  what  has  been  done  before.  A  little  research 
into  existing  software  may  save  time  in  the  long  run. 

Lesson  19:  Beware  of  the  software  part  received  from  outside  repositories.  Many  parts 
contain  useless  code.  Real  rqtplications  need  code  that  is  done  w^  and  rigorously  tested. 

Lesson  20:  Do  rutt  make  spot  fixes  without  proper  change  control. 

Lesson  21:  Have  a  test  strategy  that  includes  regression  testing. 

Lesson  22:  Have  a  thorough  integration  plan. 
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Lesson  23:  Ensure  the  Projea  Manager  has  au^rity  to  direa  efforts  and  resmarces. 

Lesson  24:  Gearty  define  the  role  of  the  Program  Manager. 

Lesson  25:  Ensure  that  the  Projea  Manager  of  an  Ada  projea  is  lUerate  in  scffware 
engineering  and  Ada. 

Lesson  26:  Establish  a  system  architeaure  (e.g.,  open  system,  client-server)  and  stidc 
Mfidt  it. 

Lesson  27:  Apply  configuration  management  and  Quality  Assurance  (QA)  to  all  parts 
of  the  system  (e.g.,  requirements,  design,  Ada  code,  dtuabase  code,  COTS  products) 
regardless  ofihe  language. 

Lesson  28:  Do  not  flood  the  team  with  untrained  people  and  expea  than  to  ga  trained 
“free"  on  the  job. 

Lesson  29:  Ensure  that  upper  managemem  and  corfiguration  management  personnel 
understand  that  they  do  not  need  to  know  how  to  program  in  Ada  to  manage  projects 
written  in  Ada.  To  be  effective,  however,  personnel  does  need  to  understand  a  little 
about  Ada  and  software  engineering. 

Lesson  30:  Provide  periodic  updates  to  mm-Ada  groiq>s  outside  die  projea.  People  not 
involved  in  Ada  projects  tend  to  ignore  the  Ada  projects. 

L2  WELLS  FARGO  NUCKO  INVESTMENT  ADVISORS 
Wells  Fargo  Nikko  Investment  Advisors  (WFNIA)  is  a  jmnt  venture  between  Wells 
Fargo  (California)  and  Nikko  Securities  (Jsq}an).  WFNIA,  a  leader  in  the  insdtutioiud 
investment  management  service  industry,  manages  large  sums  of  money  at  very  low 
percentage  rates.  The  computer  software  it  uses  is  an  important  competitive  diffmential. 
The  paragraphs  below  summarize  the  lessons  learned  from  WFNIA  efforts. 

Lesson  1:  To  use  Ada  effectively,  management  at  the  highest  level  must  be  committed 
to  Ada. 

Ixsson  2:  Ma  requires  an  up-froru  investment,  patience  to  wot  for  the  up-front 
investtnem,  and  patience  to  wait  for  the  pay  bade. 

Lesson  3:  Some  criticism,  pessimism,  and  panic  are  abnost  inevitable.  Management 
must  be  able  to  see  through  the  storm  to  the  goal  ahead. 
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Lesson  4:  Ada  must  be  sold,  and  existing  environments  (and  other  languages)  must  be 
“unsold.  “ 

Lesson  S:  Support  and  commitmem  from  other  developers  and  users  should  grow  over 
time  as  die  Umguage  has  time  to  prove  itse^. 

Lesson  6:  Tools  and  adequate  hardware  to  run  the  tools  are  needed. 

Lesson  7:  Training  is  a  must.  Ada-specific  training  and,  more  important,  software 
engineoing  training  are  required. 

Lesson  8:  A  software  repository  foundation  is  vUal  wish  both  externally  developed  and 
imemally  developed  soft^re. 

Lesson  9:  Ada  can  and  should  be  used  with  other  languages.  When  Ada  is  mixed  with 
other  languages,  the  Ada  portion  should  be  approximately  8S%. 

L3  B-2  AIRCREW  TRAINING  DEVICES 
Aviation  Week  A  Space  Technology  remits: 

The  Air  Force/contractor  team  is  developing  the  B-2  simulators  concurrently  with 
the  aircraft  in  a  program  that  stresses  close  ties  between  aircraft  and  simulator 
perscmnd  and  ease  of  modification  of  the  aircraft. 

From  the  training  perspective  alone,  the  program  presents  three  major  challenges: 

•  To  develop  the  simulators  and  aircraft  concurrently 

•  To  have  the  simulators  ready  for  use  before  the  first  aircraft 

•  To  ensure  the  simulators  match  the  current  aircraft,  but  are  designed  to  be 
updated  easily. 

(Aination  Week  A  Space  Technology,  20  August  1990,  pages  34-42) 

Steatth  Training 

The  B-2  is  the  pmetrating  bomber  of  the  future.  The  aircraft  incorporates  low- 
observable  or  "stealth”  technologies  to  reduce  its  detectable  signature  in  a  wide  array  of 
soisor  spectra. 
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lYuning  the  aircrews  to  effectively  f  f  and  apply  a  stealth  aircraft  presents  unique 
diallenges.  To  solve  those  challenges,  the  U.S.  Air  Force  turned  to  CAE-Unk,  just  as 
it  did  earlier  for  the  F-1 17A  stealth  fighter/bomber  and  for  the  SR-71  Blackbird  Program. 

The  Aircrew  Training  Devices  (ATDs)  being  developed  by  CAE-Link  for  the  B-2 
Advanced  Technology  Bomber  total  training  system  "provide  fidelity  and  training 
ciq)ability  beyond  any  device  yet  devdoped,"  according  to  the  Air  Force  ATD  Program 
Manager. 

The  B-2  ATD  program  has  taken  a  revolutionary  ai^roach  to  training  concurrency,  and 
die  simulators  being  developed  represmt  the  latest  real-time  simulation  applicaticm  of 
the  Ada  programming  language. 

Under  a  competitively  won  contract,  CAE-Unk  is  producing  three  Weapon  System 
Trainers  (WSTs),  two  Mission  Trainers  (MTs)  and  a  System  Support  Crater  (SSC). 
Northrop,  the  aircraft  prime  manufacturer,  has  overall  re^nsibility  for  aircrew  and 
maintenance  training. 

The  Electronic  Combat  Environment  for  the  B-2  ATDs  provides  a  high-density 
environment  of  up  to  12,000  threats  per  mission,  selected  from  a  threat  library  of  800 
types  such  as  radar  emitters,  surface-to-air  missiles,  antiaircraft,  and  other  aircraft.  Of 
tte  12,000  threats,  up  to  2,000  may  be  located  in  the  50,000-square-mile  mission  area, 
and  256  may  be  active  within  the  radar  horizon  of  the  aircraft.  In  effect,  B-2  aircrews 
will  be  able  to  fly  simulated  training  missions  anywhere  in  the  world  against  any 
contemporary  mission  environment. 

This  high-fidelity,  real-time  threat  environment  features  dynamic  reaction,  we^n 
deployment  with  realistic  missile  flyouts,  terrain  occulting,  and  networking  effects.  In 
addition  to  the  automatic  reaction  to  the  flight  of  the  B-2  through  the  environment, 
commands  are  accepted  in  real  time  from  the  instructional  system  to  change  the  operation 
of  threats  or  to  control  the  overall  execution  of  the  simulation.  Examples  of  the 
commands  accepted  are  as  follows: 

•  Move,  copy,  add,  delete  threats 

•  Set  threats  to  specific  modes  (search,  track,  launch,  off) 

•  Inhibit  or  activate  threats 

•  Inhibit  or  initiate  weapon  launch 

•  Initiate  aiiborne  interceptor  attacks. 

The  real-time  threat  environment  is  supported  by  an  off-line  threat  database  that  includes 
location,  operational  tactics,  networking,  signal  parameters,  we^n  characteristics, 
moving  platform  attributes,  and  Electronic  Counter-Countermeasures  (ECCM) 
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oqtabilides.  The  threat  database  uses  Government-provided  standard  intelligence  ti^ 
as  a  primary  source  of  input  data.  This  facilitates  automation  of  the  scenario-generation 
process  by  providing  an  automatic  threat  laydown  with  global  coverage,  which  is  suitable 
for  mission  rehearsal.  The  tape  update  capability  also  provides  a  rapid  and  convenient 
means  of  maintaining  currency  with  the  latest  data  available  from  the  intelligence 
community.  A  full-screen  edit  capability  is  provided  to  allow  manual  creation,  tailoring, 
and  verification  of  threat  data. 

The  B-2  computational  system  is  by  far  the  largest  real-time  simulation  plication  of 
Ada  to  date.  It  is  capable  of  handling  60  Million  Instructions  Per  Second  (NflPS).  By 
comparison,  the  B-2  simulator  has  seven  times  the  computing  capacity  of  a  B-S2  WST. 

The  B-2  ATD  system  has  more  than  1.7  million  lines  of  Ada  code.  In  addition,  the 
simulator  uses  1.7  million  of  the  2  million  lines  of  aircraft  code  to  operate  the  Aircraft 
Control  Unit  Emulators  (ACUEs).  The  emulators,  commercial  vm^ions  of  the  Paramax 
aircraft  onboard  computers,  have  slightly  enhanced  capability  and  memory.  (Software 
for  the  B-2  aircraft  is  not  written  in  Ada.) 

Concurrent  Computer  Corporation  is  supplying  CAE-Link  with  Model  3280MPS 
superminicomputers  with  19  processors  per  simulator.  The  3280s  are  connected  by  high- 
sp^  distributed  bus  links  so  that  they  can  share  memory,  processors,  and  other 
resources— more  than  60  times  faster  than  a  Local  Area  Network  (LAN)  connection 
would  permit.  Initially,  only  one-half  the  computational  system  will  be  us^  with  50% 
as  spare;  the  architecture  also  permits  100%  exj^nsion. 

Lesson  1:  In  the  early  Design  Phase,  capacity  and  performance  estimates  should  target 
resources  that  provide  at  least  a  factor  of  2  reserve.  Such  reserve  capacity  will  limit  the 
risk  of  contention’s  developing  later. 

When  the  decision  was  made  in  1984  to  use  Ada  in  the  B-2  simulators,  the  Ada  language 
had  only  recently  been  frozen  and  a  validated  Ada  compiler  did  not  exist. 

Lesson  2:  When  COTS  language  development  products  are  to  be  used,  project  staff 
should  expend  as  much  effort  as  possible  to  determine  wluch  products  best  meet  project 
needs.  Technical,  management,  and  business-sensitive  issues  and  concerns  need  to  be 
identified  and  evaluated,  and  contingencies  need  to  be  developed  where  problems  persist. 

Specially  trained  CAE-Link  Ada  developers,  working  as  a  team  with  experts  provided 
by  the  Government  and  the  Software  Engineering  Institute  (SEI),  wrote  the  software. 
CAE-Link  brought  in  experts  from  Camegie-Mellon  University  and  others  to  validate  the 
system  independently. 
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Initially,  it  was  difficult  to  leam  how  to  apply  Ada.  The  B'2  ATD,  however,  is  now 
reiQ)ing  many  of  the  prized  benefits  of  the  DOD’s  new  standard  language.  The  B-2 
training  program  has  a  proven  set  of  integrated  Ada-based  tools  and  a  disciplined, 
repeatable  process  that  fully  supports  all  life-cycle  phases.  The  investment  in  committing 
to  Ada  is  paying  for  itself  again  and  again  in  the  modification  process. 

Lesson  3:  Ifyfell-thought-out  engineering  and  management  plans  are  implemented  Math 
enough  resources,  the  project  will  be  succes^.  Moreover,  a  proven  methodology  can 
be  used  repetitively  to  evolve  the  current  and  new  systems,  based  on  the  low-risk  reused 
assets. 


The  B-2  Ada  tool  set  includes  a  specially  developed  Ada-based  configuration  management 
tool  and  a  closely  integrated  load-build  tool.  Both  tools  were  written  in  Ada  and  meet 
CAE-Link’s  standard  policies.  These  tools  are  mature  today;  however,  process 
improvement  is  considered  a  normal  part  of  the  continuing  CAE-Unk  process.  "Our 
attitude,"  says  CAE-Link  B-2  Program  Manager  Keith  Hickling,  "is  that  improvement 
is  always  possible."  For  example,  in  the  early  stages  of  the  program  it  took  nearly  6 
months  to  train  an  Ada  engineer;  today,  however,  the  training  time  is  closer  to  6  weeks, 
and  the  goal  is  to  reduce  it  to  only  3  weeks. 

"We  are  also  continually  looking  at  ways  to  improve  engineering  productivity,"  Hickling 
points  out.  Software  metrics  are  key.  "Metrics  help  us  isolate  the  right  process  areas 
to  improve."  Improvements  are  then  planned  as  part  of  the  normal  engineering  change 
process,  resulting  in  a  process  that  continually  gets  better.  "We  are  training  our 
engineers  faster,  they  are  becoming  productive  sooner,  and  we  are  increasing  our 
reusable  Ada  software.  This  reduces  cost  of  modifications  for  the  B-2  ATD  and  benefits 
the  company  and  the  customer." 

The  B-2  ATD  program  has  proven  that  the  benefits  of  Ada  are  genuine,  "but  only," 
Hickling  notes,  "if  the  front-end  investment  is  made  in  a  sound  software  process,  tool- 
set,  and  training." 

1.4  BOEING  MILITARY  AIRCRAFT  (WICHITA,  KANSAS) 

Boeing  is  involved  in  many  military  and  commercial  aircraft  ventures.  Lessons  learned 
from  these  ventures  are  related  to  the  engineering  support  area,  which  supports  the 
software  tools  and  research  needs  for  the  aircraft  development  programs.  The  paragraphs 
below  summarize  lessons  learned  as  they  relate  to: 

•  Portability  (Lessons  1  and  2) 

•  Separate  Compilation  (Lesson  3) 

•  Rttulability  (Lesson  4). 
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1.4.1  Portability 

Lesson  1:  Canfid  technical  management  of  the  development  of  code  directives, 
guidelines,  and  formulations  enables  project  staff  to  maximize  the  amount  of  fidly 
portable  code  that  is  produced.  The  portability  of  Ada  programs  between 
iifiplfftnnntarinn  is  now  good  and  has  improved  considerably  since  the  initial  releases  of 
Ada  implementations.  What  is  significant  relative  to  other  languages  is  that  the  class  of 
problems  that  can  be  written  without  requiring  implementation-dependent  code  is  larger 
than  in  most  other  languages.  This  class  includes  tasking  and  time-dependent  programs. 

Lesson  2;  The  availability  of  a  large  suite  of  formal  validation  tests  and  use  of  m 
independent  testing  organization  help  ensure  the  basic  qualifications  of  vendor-supplied 
products.  Use  of  these  tests  and  an  independent  team  do  not  replace  project  staffs 
detailed  analysis  and  testing,  but  they  do  help  eliminate  marginal  products.  This 
validation  process  will  become  more  important  as  we  move  to  Ada  94  and  other  object- 
based  languages  (e.g.,  C-h-h). 

The  Ada  Compiler  Validation  Capability  (ACVC)  tests  and  the  Language  Control  Board 
have  been  fairly  successful  in  avoiding  the  creation  of  incompatible  versions  of  Ada. 
This  reduction  in  the  number  of  incompatible  versions  helps  promote  portability.  Some 
problems  still  exist  in  this  area.  For  example,  some  implementations  do  not  support 
preemptive  priority  scheduling,  presumably  because  the  ACVC  tests  do  not  test  for  it. 
The  situation  in  Ada,  however,  is  much  better  than  in  many  other  languages  (e.g.,  C, 
C++,  and  FORTRAN). 

1.4.2  Separate  Compilation 

Ada  provides  for  the  sqiarate  compilation  of  units  and  will  enforce  strong  typing  between 
sqiarately  compiled  units.  This  is  a  significant  advance  over  the  independent  compilation 
of  other  languages  in  which  type  checking  is  often  lost  between  units  (or  deferred  until 
run  time).  A  compilation  system  can  provide  an  automatic  recompilation  facility  to 
prevent  dependent  units  from  becoming  out  of  date.  Although  this  facility  is  not 
available  on  all  implementations,  the  checking  and  reporting  on  errors  when  obsolete 
units  are  encountered  is  universal  and  very  helpful. 

Lesson  3:  Lessons  learned  with  respect  to  portability  (see  Lessons  1  and  2)  also  apply 
to  separate  compilation.  An  Ada  programmer  quickly  learns  to  take  for  granted  the 
separate  compilation  and  the  type-safe  checking  it  provides  and  can  easily  forget  how 
difficult  it  is  to  track  down  errors  when  using  "independent”  compilation  in  other 
languages.  Neither  the  fact  that  Ada’s  separate  compilation  facility  becomes  invisible  to 
users  nor  the  fact  that  it  was  one  of  the  explicit  goals  of  the  language  the  achievement 
of  which  is  not  surprising  should  detract  from  the  value  that  the  facility  provides. 
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1.4.3  Readability 

liCsson  4:  Controlled  use  of  Ada  language  constructs  results  in  uniform  and  minimally 
compkx  code,  thus  maxirmzing  readability.  It  is  possible  to  write  some  very  obscure 
code  in  Ada  by  using  overloading  and  derived  types  and  multiple  levels  of  generic  units. 
In  general,  however,  the  language  permits  most  programming  tasks  to  be  coded  in  a 
£uriy  straightforward  way.  This  language  power  facilitates  development  of  readable 
programs.  Programmers  do  not  often  have  to  "code  around"  limitations  in  the  language 
(or  use  vendor-specific  extensions)  as  is  too  often  necessary  in  other  languages  (e.g., 
doing  dynamic  allocation  in  FORTRAN,  operating  on  unconstrained  types  in  standard 
Pascal,  writing  functions  in  COBOL). 

1.5  COULTER  ELECTRONICS:  Ada  FOR  CYTOMETRY 

Coulter  Electronics  develops  machines  to  analyze  blood.  The  paragraphs  below 
summarize  lessons  learned  on  three  small  Ada  projects  that  run  on  a  Personal  Computer 
(PC)  platform. 

Lesson  1:  Look  at  the  language  and  the  constructs  to  be  used  and  decide  on  an 
environment. 

Lesson  2:  Evaluate  your  needs  and  then  ewduate  the  compilers  that  run  on  your 
particular  platform. 

Lesson  3:  Look  at  external  software  programs  that  have  to  work  with  your  particular 
program. 

Lesson  4:  Ensure  that  the  compiler  has  a  method  for  accessing  external  hardware 
interfaces  if  the  project  equipment  has  such  interfaces. 

Lesson  5:  Remember  that  “optimization'^  should  minimize  the  code  size  not  Just  remove 
“dead  code.  “ 

Lesson  6:  Recognize  that  reuse  can  be  a  major  factor  in  code  development  if  looked  at 
from  the  beginning. 

1.6  AN/UYS-2A  PROJECT 

The  AN/UYS-2A,  which  is  under  the  direction  of  the  Naval  Sea  Systems  Command 
(NAVSEA)  PM0^28,  is  a  programmable,  data  flow,  high-throughput,  modular  Navy 
standard  signal  processor,  llie  AN/UYS-2A  consists  of  a  family  of  signal  processors 
that  meets  the  diverse  environmental  requirements  of  ship,  shore,  submarine,  and  aircraft 
Anti-Submarine  Warfare  (ASW)  platforms.  Because  of  its  design,  the  AN/UYS-2A  is 
easier  to  program  and  costs  less  over  the  system  life  cycle  than  the  previous  system.  The 
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AN/UYS’2A  is  a  Standard  Embedded  Computer  Resource  (SECR)  and  is  not  designed 
to  meet  or  counter  any  specific  threat  on  a  stand-alone  basis. 

The  basic  AN/UYS-2A  is  composed  of  different  combinations  of  seven  Functimial 
Elements  (FEs):  Arithmetic  Processors  (APs),  Input  Signal  Conditioner  (ISC),  Global 
Memories  (GMs),  Input/Output  Processors  (lOPs),  a  Command  Prt^ram  Processor 
(CPP),  a  Scheduler  (SCH),  and  a  Data  Transfer  Network  (DTN).  Additional  fiincticmal 
dements  may  be  added  to  the  basic  AN/UYS-2A  processing  csqpabilities.  These  dements 
can  be  matched  to  each  weapon  system’s  lequiremoits  by  selecting  the  combinatitm  of 
APs,  GMs,  lOPs,  and  ISCs  that  best  satisfy  the  requirements  of  the  individual  we^)on 
system.  The  AN/UYS-2A  is  also  modular  at  the  logistics  levd.  That  is,  each  of  the 
seven  functional  elements  is  built  from  a  common  set  of  format  E  Standard  Electronic 
Module  (SEM)  cards.  Although  the  terminology  has  changed  from  SEM  to  Digital 
Electronic  Module  (DEM),  many  documents  still  use  the  term  SEM.  The  terms  are 
interchangeable. 

Lesson  1:  When  selecting  a  host  computer  as  the  Application  Development  Facility, 
ensure  the  selected  host  computer  supports  Ada  so  thm  (^plication  developers  do  not 
need  to  purchase  multiple  hosts  to  develop  application  softi\^e.  The  SEM  B  ANAJYS- 
2*s  CPP  used  an  embedded  AN/UYK-44(V)  card  set  that  ran  the  Navy’s  Compiler 
Monitor  System-2  (CMS-2)  language.  Because  the  CMS-2  language  software 
devdopment  tools  reside  on  the  VAX  environment,  the  decision  was  made  to  select  the 
VAX  1 1/780  as  the  ADF  host  computer.  The  SEM  B  AN/UYS-2’s  CPP  uses  a  Motorola 
68020  architecture  and  was  required  to  use  Ada  as  the  AN/UYS-2  Command  Program 
language.  Unfortunately,  an  Ada  M68020  cross-compiler  was  not  available  for  the  VAX 
11/780;  therefore,  the  decision  was  made  to  use  a  Telesoft  Ada  compiler  environment 
running  on  a  Sun  platform. 

Lesson  2:  When  selecting  Ada  products,  ensure  that  the  Ada  vendor  can  provide  a  JuU 
spearum  of  products  fi.e,,  hosts,  cross  compilers.  Run-time  Kernels).  Avoid  using 
multiple  vendors  when  possible.  The  Ada  environment  selected  was  a  combination  of 
Telesoft’s  compiler  and  Ready’s  Run-Time  Ada  (RTAda)  extensions.  The  chronological 
sequence  of  events  was  as  follows: 

•  RTAda  was  purchased  from  Ready  Systems. 

•  Ready  Systems  contracted  with  Telesoft  for  the  Ada  compiler  and  run-time 
inter£u:e  code. 

•  Ready  Systems  modified  the  run-time  code  to  support  the  Ada  Run-Time  Executive 
(ARTX). 
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•  Ready  Systems  integrated,  sold,  and  maintained  the  RTAda  product  for  AN/UYS- 
2A. 

•  The  internal  contract  agreement  between  Ready  Systems  and  Telesoft  expired  on 
31  December  1990. 

•  Ready  Systems  stopped  selling  and  supporting  the  RTAda  product. 

•  The  AN/UYS-2  customer  could  not  purchase  the  RTAda  product  or  services. 

•  AT&T  contracted  with  Telesoft  to  develop  a  Telesoft  Run-Time  Environment 
(TeleAdaExec). 

Lesson  3:  Select  a  well-established  Ada  vendor  who  demonstrates  willingness  to  help 
software  developers  move  code  to  new  versions  of  their  compilers.  The  Telesoft  compiler 
was  upgraded  several  times  during  the  SEM  B  AN/UYS-2A  development  effort.  Versimi 
1.3  was  upgraded  to  4.1A  and  4.1A  to  4.1C.  Although  the  modifications  enhanced  the 
compiler  by  providing  more  complete  data  and  path  checking  and  greater  code  efficiency, 
they  resulted  in  additional  compiler  restrictions.  Consequently,  some  Command  Program 
Ada  code  had  to  be  rewritten  so  that  it  would  be  compatible  with  the  newer  compiler 
version. 

Lesson  4:  Establish  a  close  working  relationship  with  the  Ada  vendor  and  define  project 
needs  as  early  as  possible.  Plan  Ada  upgrades  in  a  systematic  and  controlled  manner. 
On  the  AN/IJYS-2A  project,  special  efforts  were  made  in  working  with  Telesoft  to 
determine  the  direction  of  future  compiler  upgrades.  Project  management  and  staff  also 
tried  to  communicate  to  Telesoft  the  evolving  program  needs  and  concerns. 

1.7  Ada  EXPERIENCE  AT  THE  NAVAL  RESEARCH  AND  DEVELOPMENT 
CENTER 

In  1988,  the  support  staff  and  the  contractor  of  the  Naval  Research  and  Development 
(NRaD)  Center  Code  924  began  the  transition  from  use  of  CMS-2  and  its  traditional 
software  architecture  to  Ada  and  an  object-based  design  philosophy.  This  change  was 
prompted  by  the  decline  of  the  then-current  product  line  into  a  caretaker  status,  without 
funds  to  match  the  magnitude  of  knowledge  needed  to  protect  Government  interests. 

The  situation  presented  a  rare  opportunity  both  to  accq>t  the  challenge  of  transitioning 
from  CMS-2  to  Ada  and  to  document  that  experience.  Contracting  was  being  performed 
under  a  time-and-materials  contract,  thereby  simplifying  statistical  measurements  because 
such  contracts  are  monitored  on  a  labor-hour  basis.  The  new  software  products  to  be 
implemented  in  Ada  included  CMS-2  source  analysis  tools;  data  reduction  programs;  and 
real-time,  interactive  PC-based  products.  It  should  be  noted  that  comparing  the  statistical 
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numbers  of  one  project  to  another  is  difficult  because  there  are  so  many  variables.  It  is 
better  to  compare  baseline  to  baseline  within  a  given  project.  Evra  then  there  can  be 
distortions. 

The  paragraphs  below  summarize  the  lessons  learned  from  a  managemmt  perspective 
rather  than  fiom  a  programmer’s  perspective.  Programmers  would  be  more  interested 
in  language-specific  application  lessons. 

Lesson  1;  The  transition  to  object-based  design  and  use  of  Ada  enhanced  productiwty. 
It  decreased  integration  time  because  there  were  fewer  errors  and  less  need  to  rework 
code.  The  older  CMS-2  software  engineering  process  as  applied  to  systems 
programming  in  NRaD  yielded  a  productivity  rate  of 250  Source  Lines  Of  Code  Per  Staff 
Month  (SLOC/SM).  Transitioning  to  Ada  and  adopting  an  object-based  approach 
increased  the  productivity  rate  by  24%  (i.e.,  310  SLOC/SM).  The  expressive  power  of 
Ada  aim  increased  productivity.  Function  Point  (FP)  productivity  tables  show  that  an 
FP  implemented  in  CMS-2  requires  approximately  105  SLOC,  whereas  Ada  only 
requires  70  SLOC.  The  productivity  advantages  became  apparent  to  the  NRaD  support 
staff  as  a  result  of  Ada’s  support  of  abstraction  and  encapsulation  and  the  rapidity  with 
which  the  Integration  and  Test  Phase  of  a  given  implementation  was  completed. 

An  analysis  of  the  errors  encountered  during  the  production  process  showed  a  21% 
reduction  in  errors.  Although  industry  samplings  show  even  greater  reduction  (i.e., 
24%),  further  analysis  is  required  to  ensure  that  the  basis  for  comparison  is  consistent. 
Code  924  staff  believe  that  their  figure  represents  a  more  arduous  test  process.  Factors 
contributing  to  this  improvement  are  the  level  of  error  checking  in  Ada  compilers,  use 
of  Ada  features  that  support  a  self-documenting  style,  and  implementation  of  information¬ 
hiding  concepts  that  r^uce  the  side  effects  found  from  the  use  of  traditional  common 
stores. 

Lesson  2:  The  use  of  automated  tools  and  Ada  have  enhanced  our  ability  to  maintain 
develop^  products  their  documeruation.  Maintainability  has  been  greatly  enhanced. 

Use  of  a  software  engineering  process  that  combines  the  use  of  Ada  as  a  Program  Design 
Language  (PDL)  and  emphasis  on  code  readability  has  allowed  errors  to  be  corrected 
r^idly.  ^velopment  and  use  of  an  Ada  Reuse  Library  Browser  (ARLB)  further 
enhanced  maintainability.  The  ARLB  allows  the  programmer  to  r^idly  traverse  call 
trees  and  WITH  dependencies  to  focus  on  individu^  package  bodies  where  source  and 
design  representation  modifications  are  made  interactively.  The  ARLB,  supported  by 
disciplined  programming  standards,  has  led  to  automated  design  document  production 
derived  from  the  Ada  source  library. 

Lesson  3:  Project  management  should  expect  that  at  least  50%  of  the  development  time 
will  be  spent  in  the  Requirements  Analysis  and  Design  Phases.  Deriving  the  objects  and 


1-32 


Department  of  the  Navy 


Lassons  Learned 


their  associated  operations  into  Ada  package  specifications  is  an  iterative  process 
requiring  considerable  time  and  interaction  among  the  lead  designers.  Elaborating  a 
design  to  implement  those  objects  and  operations,  using  an  Ada  PDL,  into  the  Ada 
package  bodies  represents  an  additional  up-front  investment.  Patience  was  required 
because  the  overall  design  process  consumed  50%  of  the  implementation  time.  Afta* 
coding  began,  however,  it  progressed  rsqpidly  and  integration  occurred  quickly  with  fewer 
errors.  The  overall  schedule  (in  months)  seemed  to  be  the  same  as  that  for  a  CMS-2 
program;  however,  a  smaller  staff  was  required.  We  are  not  sure  whether  increasing  the 
number  of  staff  members  would  shorten  the  schedule. 

Lesson  4:  Attitude  is  a  key  factor  in  transitioning  engineering  personnel  to  modem 
software  engineering  and  Ada.  Success  will  only  come  from  a  well-motivated  team  that 
is  committed  to  the  tool,  technology,  and  project. 

Training  is  critical  to  preventing  the  application  of  Ada  in  the  context  of  traditional  CMS- 
2  design  disciplines.  The  Ada  language  was  designed  to  support  more  modem  software 
engineering  approaches  and  should  be  used  in  that  context.  The  critical  paradigm  shift 
is  one  from  the  classical  hierarchy  of  processes  to  one  of  object  orientation.  For  most 
programmers,  this  shift  can  be  achieved  in  4  to  9  months  through  a  combination  of 
classroom  training  and  on-the-job  experience.  New  college  graduates  a(hq)t  quickly. 
Many  of  the  older  CMS-2  programmers  may  never  make  the  transition.  Older 
programmers  should  not  be  forced  into  a  position  of  resistance  to  change.  To  be 
successful,  the  job  must  be  in  the  hands  of  l^ievers. 

Traditional  CMS-2  systems  have  been  built  with  a  specific  computer  in  mind.  The 
software  was  dependent  on  the  machine-sensitive  constructs  of  the  language  of 
implementation  and  the  service  calls  of  the  chosen  executive.  Dialect  difference  between 
implementations  of  purported  standard  languages  and  operating  systems  have  limited  the 
market  of  the  implemented  systems  to  hardware  supported  by  the  compiler  or  operating 
system  vendor.  With  Ada’s  rigorous  standards,  c^e  has  benefited  from  the  ability  to 
draw  software  components  from  a  common  library  and  use  compilers  of  multiple  vendors 
to  place  its  products  on  a  variety  of  target  hardware— an  important  consideration  in  an 
era  of  migration  from  gray  boxes  to  the  richer  mix  of  architectures  in  the  commercial 
arena. 


1.8  TACTICAL  AIRCRAFT  MISSION  PLANNING  SYSTEM 
The  Tactical  Aircraft  Mission  Planning  System  (TAMPS)  is  hosted  on  the  Navy’s 
standard  Desktop  Computer  (DTC-2).  With  the  release  of  the  New  Tactical  Advanced 
Computer  (TAC-3)  as  an  upgrade  replacement  for  the  DTC-2,  Naval  Air  Warfare 
Center,  Aircraft  Division  Warminster  (NAWC-AD  WAR)  is  tasked  to  evaluate  the 
TAMPS  software  portability  to  the  TAC-3  platform. 
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The  subsections  below  identify  problems  associated  with  porting  TAMPS  software  from 
the  DTC-2  to  the  TAC-3  platform  and  illustrate  the  magnitude  of  each  problem. 

1.8.1  TAMPS  TAC-3  Hardware  and  Software  Configuration 

The  TAC-3  hardware  suite,  delivered  to  the  NAWC  TAMPS  laboratory  on  13  July  1992, 
consisted  of  the  Hewlett-Packard  (HP)  9000  Soles  7S0  with  128  megabytes  (MB)  of 
inenKiry,  two  1.2-gigabyte  (GB)  disk  drives,  oim  4-millimeter  (mm)  Digital  Audio  T^ 
(DAT3  drive,  and  one  monitor.  The  TAC-3  software  includ^  the  HP-UX  Operating 
System,  the  Irvine  Compiler  Corporation  GCC)  Ada  compiler,  an  HP-UX  FORTRAN 
compiler,  and  an  HP-UX  C  compiler.  This  system  configuration  is  only  sufficient  to 
recompile  and  to  evaluate  TAMPS  code  por^ility.  A  complete  hardware  suite  is 
requir^  to  evaluate  TAMPS  executability  afto  all  compihdon  errors  have  been 
resolved. 

1.8.2  TAMPS  Evaluation  Results 

NAWC  used  the  TAMPS  5.0x3  source  code  to  evaluate  its  portability  from  the  DTC-2 
to  the  TAC-3  platform.  The  evaluation  task  was  divided  into  the  following  areas: 
Hardware,  Operating  System,  Compiler  and  Sui^rt  Software,  and  Peripheral  and 
Device  Driver.  The  subsections  below  list  problems  uncovered  for  this  task  for  each 
area  and  provide  impact  assessments. 

1.8.2.1  TAMPS  Hardware  Assessment 

Because  the  internal  data  representation  of  the  two  machines  is  the  same,  the  TAMPS 
databases  can  be  transferred  to  the  TAC-3  hardware  and  used  without  any  conversion. 
NAWC  wrote  a  routine  to  read  or  write  data  onto  a  file  on  the  DTC-2  and  used  the  same 
routine  to  read  the  data  back  onto  the  TAC-3.  Hie  results  showed  that  the  intmnal  data 
rqiresentation  on  both  systems  was  the  same.  BTG,  Inc.  (i.e.,  the  TAC-3  technical 
support  contractor)  confirmed  our  results. 

The  TAC-3  graphics  processors  support  two  independent  workstations  and  a  DBA  station 
with  X11R4  libraries,  which  will  satisfy  TAMPS  requirements.  TAMPS  software, 
however,  needs  to  be  tested  on  the  TAC-3  hardware  to  confirm  that  all  TAMPS  graphics 
requirements  will  run  without  further  software  modifications. 

1.8.2.2  TAMPS  Software  Assessment 

After  the  TAC-3  hardware  suite  was  set  up,  NAWC  began  TAMPS  software  assessment. 
The  HP-UX  Operating  System  (System  V),  ICC  Ada  compiler,  HP-UX  FORTRAN 
compiler,  HP-UX  C  compiler,  and  X11R4  libraries  were  used  to  assess  TAMPS  code. 

The  Ada,  C,  and  FORTRAN  compilers  were  installed  and  verified.  Then  the  required 
libraries  were  created  as  indicat^  in  TAMPS  makefiles.  Because  the  "makefile* 
commands  on  the  two  systems  were  different,  new  TAMPS  makefiles  were  written  to 
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recompile  TAMPS  on  HP-UX. 

The  HP  Window  Manager  (Vuewm)  and  X11R4  libraries  supplied  with  HP-UX  were 
tested  by  running  standard  X-based  s^lications.  In  addition,  the  manual  pages  for  the 
Vuewm  were  compared  with  those  of  the  Motif  Window  Manager  for  discrepancies.  A 
list  of  system  calls  in  TAMPS  was  gathered  by  the  UNIX  ”grq)"  command.  The 
parameters  and  usage  of  the  system  calls  were  compared  to  determine  the  differences. 
Ada,  FORTRAN,  and  C  files  were  recompiled,  and  error  listings  were  examined  to 
determine  the  problems  and  solutions. 

Because  of  the  incompatibilities  between  the  ICC  Ada  compiler  and  the  Sun  Ada 
compiler,  NAWC  is  acquiring  the  Alsys  Ada  compiler  to  perform  another  TAMPS  Ada 
code  assessment  at  the  NAWC  laboratory. 

Lesson  1:  Before  selecting  vendor  products,  it  is  important  to  test  them  extensively  to 
ensure  that  they  meet  a  project’s  specific  needs. 

1.8,2^  Operating  System 

The  operating  environment,  Vuewm,  is  an  XI 1  window  manager  based  upon  the  Motif 
Window  Manager  (mwm,  version  1.1).  Vuewm  is  an  integral  part  of  die  HP  Visual 
User  Environment  (HP  VUE).  It  communicates  with  and  facilitates  access  to  the  other 
components  in  the  environment.  Vuewm  provides  the  same  window  management  and 
limited  session  management  functionality  as  mwm.  It  allows  the  user  to  control  window 
size,  position,  state  (iconic  or  normal),  input  focus  ownership,  and  the  like.  TAMPS  will 
be  able  to  run  in  this  environment  with  little  problem. 

Most  of  the  system  calls  used  in  TAMPS  (DTC-2/BSD  Operating  System)  are  compatible 
with  those  in  the  TAC-3  (System  V  Operating  System)  except  for  the  following  types  of 
problems: 

•  Different  constants 

•  Function  names 

•  Unsupported  asynchronous  Input/Output  (I/O) 

•  System  calls  that  are  not  in  TAC-3. 

All  shared  memory  calls  are  compatible  between  the  DTC-2  and  the  TAC-3  system. 
This  area  needs  to  be  tested  when  of  the  other  problems  are  resolved  to  confirm  that 
TAMPS  will  run  without  further  software  modifications. 

I.8,2.4  Compiler  and  Support  Software 

Of  the  SS  C  flies  within  TAMPS  code,  44  files  were  compiled  without  errors  and  1 1  files 
(or  20%)  could  not  be  compiled  because  of  the  following  types  of  problems: 
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•  Different  library  functions 

•  The  nonportable  code  for  system  functions  in  the  Computer  Software  Conftguration 
Items  (CSCIs). 

For  all  C  implementations,  new  code  had  to  be  generated  to  handle  the  library  functions 
and  nonportable  code  problems. 

All  TAMPS  FORTRAN  code  has  been  recompiled  in  the  TAC-3  system  with  the  HP-UX 
FORTRAN  compUer.  Of  the  3,453  FORTRAN  files  within  TAMPS  code.  3,392  files 
(98%)  were  compiled  without  errors  and  61  files  (or  2%)  could  not  be  compiled. 
Problems  found  while  recompiling  TAMPS  FORTRAN  code  are  as  follows: 

•  Overlapping  data  initializations.  The  FORTRAN  compiler  does  not  allow  a 
variable  to  be  initialized  more  than  once  in  a  data  statement. 

•  Error  due  to  the  alignment  in  the  common  block.  Integer  variable  must  start  at  an 
odd  address. 

•  ExpUdt  dtfimtion  of  format  statement  needed. 

•  Character  string  referenced  out  of  range.  A  character  string  is  defined  with  a 
length  N  and  later  used  with  a  length  of  N+m. 

•  Nbnlogical  etqtression  in  IF/DO  WHILE  statement.  An  integer  variable  is  used  as 
a  logical  variable. 

•  Nonpositive  label.  A  label  of  zero  is  used  in  TAMPS  code.  A  label  must  be 
within  the  range  of  1  to  99999. 

•  Argument  with  the  same  name  as  INTRINSIC  Junction.  TAMPS  code  uses  the 
INTRINSIC  function  "FLOAT"  as  one  of  the  arguments  in  a  parameter  to  a 
subroutine. 

•  Adjustable  array  in  common  block.  In  a  few  places,  TAMPS  code  defined  an 
array  in  a  common  block  as: 

-  Integer  length 

-  Common  XXX  /  Array  YYY(LENGTH)  /. 
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This  FORTRAN  compiler  cannot  figure  out  the  size  of  LENGTH  because  it  is 
declared  but  undefined  at  this  time.  Therefore,  it  cannot  declare  the  array  YYY. 

These  FORTRAN  problems  have  a  minimal  impact  on  TAMPS  code. 

All  TAMPS  Ada  code  has  been  recompiled  in  the  TAC-3  system  with  the  Ada  compiler 
ftom  ICC.  A  few  of  die  problems  with  TAMPS  Ada  code  were  serious  because  of  the 
incompatibility  between  the  DTC'2  Sun  Ada  compiler  and  the  TAC-3  ICC  Ada  compiler. 
Independent  research  had  shown  that  many  users  were  having  trouble  with  the  ICC 
product.  Two  basic  modifications  were  required  before  Ada  code  could  be  compiled 
with  the  ICC  Ada  compiler.  First,  the  ICC  Ada  compiler  treated  "subtype  integer”  in 
the  same  way  as  it  did  "standard.int^er”.  Therefore,  the  basic  integer  types  in  the 
"basic jlata_typesj)kg.ada*  package  were  redefined.  Second,  the  "LANGUAGE" 
package  was  Sun  Ada  compiler’s  unique  package,  and  all  pragma  statements  referencing 
the  LANGUAGE  package  need  to  be  commented  out. 

After  completion  of  the  above  basic  modifications,  2,969  Ada  source  files  remained 
within  TAMPS  code:  352  Hies  that  were  compiled  without  errors  and  2,617  files  (or 
88%)  that  could  not  be  compiled.  These  errors  result  from  the  different  implementations 
of  tire  two  compilers. 

Lesson  2:  Many  details  in  the  implementation  process  are  not  controlled  by  AHL-STD- 
1815A  or  the  associated  validation  suite  for  the  Ada  language.  Project  staff  should 
perform  sufficiently  detailed  analysis  of  particular  implementations  so  that  they  can 
correctly  assess  impact  when  changing  configurations. 

The  following  paragr^hs  list  all  general  problems  found  while  recompiling  TAMPS  Ada 
code: 


•  Misalignment.  An  integer  field  declaration  in  a  record  must  lie  in  a  word 
boundary. 

•  Dynamic  Generic  Instantiation.  UNCHECKED_CONVERSION  cannot  be 
instantiated  with  dynamically  sized  type  with  the  ICC  Ada  compiler. 

•  Unsupported  MachinejCode  Package.  TAMPS  uses  inline  expansion  of  low-  level 
machine  code  provided  by  the  Sun  Ada  compiler’s  "Machine_Code”  package.  The 
ICC  compiler  does  not  provide  a  Machine_Code  package  for  the  TAC-3  platform. 

•  Unsupported  ERRNO  Package.  TAMPS  uses  the  error  package  "ERRNO,"  which 
is  specific  to  Sun’s  Ada  compiler.  This  package  is  not  provided  with  the  ICC  Ada 
compiler. 
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•  Unsupported  System  ”+  ”  Function.  Function in  Sun’s  system  package  does 
not  comply  with  MIL-STD-1815A.  This  Unction  is  an  extension  provided  by  the 
Sun  Ada  compiler  but  not  by  the  ICC  Ada  compiler. 

•  Unsupported  System.  No_Addr  Type.  The  type  "No_Addr"  in  Sun’s  system 
package  does  not  comply  with  MIL-STD-181SA.  This  type  is  an  extension 
provided  by  the  Sun  A^  compiler  but  not  by  the  ICC  compile. 

•  Cakndar.LocalJ\me  Package.  The  ’’Localjrime”  package  within  the  Calendar 
Package  does  not  comply  with  MIL-STD>181SA.  TAMPS  modifies  a  body  part 
of  the  Calendar.Local_Time  package  and  incorporates  it  into  the  standard  Calendar 
package.  Problems  occurred  when  attempts  were  made  to  incorporate  it  into  the 
Calendar  package  provided  by  the  ICC  compiler. 

•  Disallowed  Zero-Length  Field  in  Record.  In  TAMPS  code,  a  field  length  of  zero 
in  a  variant  record  is  defined  as  null.  The  ICC  compiler  interprets  it  as  a  missing 
field  and  indicates  it  as  an  error. 

•  Unincorporated  Parent  Package  Name.  When  a  function  is  defined  in  a  sqxuate 
procedure,  the  ICC  Ada  compiler  requires  the  parent  package  name  must  be  "with* 
into  the  function  code.  The  Sun  Ada  compiler  does  not  have  this  requirement. 

•  Unstqjported  VADS  Configuration  Package.  TAMPS  uses  a  Verdix  Ada 
Devdopment  System  (VADS)  Configuration  Package  Specification  for  Sun4  BSD 
UNIX.  This  package  specification  defines  and  describe  the  components  that  the 
user  must  provide  to  configure  the  VADS  self-hosted  Run-Time  Environment 
(RTE)  for  a  user  application  program.  Users  have  the  choice  of  using  the  Sun- 
supplied  memory  allocation  packages  or  implementing  their  own  algorithms. 
MDMSC  should  try  to  avoid  all  machine  or  compiler  dependencies  in  the  TAMPS 
code. 


The  problems  associated  with  the  incompatibilities  of  the  two  compilers  required  NAWC 
to  use  another  vendor  product,  (i.e.,  the  Alsys  Ada  compiler)  to  reduce  the  impacts  on 
the  TAMPS  Ada  code. 

Lesson  3;  Stc^  should  do  up-fivru  technical  evaluations. 

Other  areas  of  concern  related  to  porting  projects  include  the  following: 


1-38 


Department  of  the  Navy 


LMMII*  iMMIMd 


•  File  structure  and  handling  systems  that  are  in  use 

•  Perij^ieral  and  device  drivers  movement 

•  Spe^  iq)plication  software  packages. 

L9  ADVANCED  FIELD  ARTILLERY  TACTICAL  DATA  SYSTEM 
The  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS)  is  a  system  of  computers, 
printers,  di^lays,  and  software  that  helps  Army  commanders  plan,  direct,  and  control 
artillery  fire  in  combat  situations.  AFATDS  was  intended  to  rq)lace  the  former  Tactical 
Fire  Direction  (TACFIRE)  system. 

AFATDS  was  a  concept  evaluation  effort  that  b^an  in  May  1984  with  Magnavox 
Electionic  Systems  as  the  prime  contractor.  The  paragr^s  below  summarize  die 
lessons  learned  during  this  effort. 

Lesson  1:  Anticipate  trouble  with  the  Ada  development  tooh/environmtnt,  no  matter  who 
is  supplying  them  or  when  you  get  them.  Especially  expea  problems  with  the  ability  cf 
the  Ada  Run-Time  Executive  to  meet  all  of  the  project  needs.  The  Army  had  required 
Ada  as  the  High  Order  Language  (HOL).  During  the  Source-Selection  Phase,  only  three 
validated  compilers  were  available,  none  of  which  could  down-line  load  to  a  target 
processor  that  met  the  AFATDS-derived  requirements.  The  language,  methodology,  and 
tools  were  new;  the  approach  was  to  be  "software  first." 

Lesson  2:  Budget  for  traimng.  Be  prepared  for  and  include  additional  funds  for 
training  over  a  long  period  of  time.  Note  that  for  das  training  to  be  most  effective,  it 
must  be  accon^lished  Just  bffore  or  during  die  development  effort.  Magnavox 
recognized  that  leal-dme  expertise  in  Ada  did  not  exist  and  immediately  wrnit  to  the  Ada 
community  to  establish  a  comprehensive,  long-term  Ada  and  software  engineming 
training  program.  Magnavox  also  proceeded  to  hire  selected  consultants  and 
subcontractors  to  handle  specialty  items  (e.g;,  dat^ase  design). . 

Lesson  3:  Anticipate  that  original  estimates  for  support  hardware  and facilities  mil  have 
to  be  revised.  In  this  project,  original  estimates  quadrupled  for  support  hardware  and 
facilities.  Magnavox  also  purchased  multiple  mainframe  and  workstation  computing 
systems;  however,  these  resources  proved  insufficient  but  were  relatively  easy  to 
upgrade. 

Lesson  4:  To  accomplish  the  project  succesffuUy,  ensure  that  both  the  contractor  and 
Government  teams  are  knowledgeable  about  and  understand  the  rationale  for  all 
software-related  topics.  At  that  time,  none  of  the  DOD  policy  standards  had  been 
updated  (this  is  still  true  today  in  many  cases),  and  very  few  people  on  the  Government 
side  understood  their  ramifications.  The  Army  had  taken  a  sound,  long-term  view  when 
it  awarded  this  contract,  but  early  into  implemoitation,  the  pressure  of  outside  scrutiny 
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began  to  erode  that  resolve.  1111$,  coupled  with  limited  understanding  of  Ada  and  its 
software  engineering  ramifications,  caused  serious  disconnects  to  develop  between  the 
contractor  and  the  Army  acquisition  team  (e.g.,  "Where’s  the  code?"  syndrome). 

Lesson  5:  Have  the  team  develop  a  ^4able  technical/management  plan  and  adhere  to  it 
so  that  requirements  and  design  can  be  implemented  correafy.  Although  it  mil  take 
longer  u>  begin  writing  the  actual  code,  it  will  be  worth  it  because  fewer  design  problems 
will  be  encountered  during  test  and  integration.  Some  of  the  hardest  work  will  be 
associated  with  trying  to  handle  the  extemai  nay  sayers. 

Lesson  6:  Report  major  problems  up  the  line  as  encountered.  Magnavox  and  the  Army 
Program  Office  were  never  assertive  in  promoting  dieir  initiatives.  Had  they  been,  many 
of  the  extemai  groups  might  not  have  felt  compelled  to  investigate,  and  more  time  would 
have  been  available  to  resolve  the  technical  problems.  Others  can  benefit  from  lessons 
learned  only  if  they  are  informed  about  them.  Such  publicity  could  have  helped  the 
AFATDS  project  and  provided  insight  to  other  projects  that  were  beginning. 

Lesson  7:  Do  not  mistakenly  blame  software  development  for  failure.  Cartful  scrutiny 
of  many  projects  frequently  shows  that  things  otlUr  than  software  development  are 
responsible  for  failure.  For  AFATDS,  three  formal  General  Accounting  Office  (GAO) 
evaluations  were  performed  and  report  on  during  1986-87:  GAO/NSIAD-86-184FS, 
GAO/NSIAD-86-212FS,  and  GAO/NSIAD-87-198BR.  None  of  these  reports  identified 
Ada  as  a  prt^lem.  Major  impact  items  included  the  reduction  in  scope  bemuse  of  budget 
constraints,  the  changing  of  requirements  to  accommodate  different  equipment  and 
software,  and  the  Army’s  ability  to  manage  this  ^tivity. 

LIO  AN/BSY-2 

The  AN/BSY-2  Submarine  Combat  System  (SCS)  is  the  suite  of  hardware,  software,  and 
equipment  that  will  be  used  on  the  Department  of  the  Navy’s  (DON’S)  next-generation, 
attack-class  submarine,  the  SSN-21.  General  Dynamics  Electric  Boat  Division  is 
building  the  ftrst  hull  in  this  series,  which  will  be  r^y  in  1994. 

Lesson  1:  Wien  extemai  schedule  constraints  exist,  the  level  of  planning  and  execution 
analysis  becomes  much  more  critical.  This  was  especially  true  for  BSY-2  because  of  the 
estimated  volume  of  software  and  separately  defined  hull  completion  dates.  The 
AN/BSY-2  software  is  beini.  developed  under  DOD-STD-2167A  in  an  effort  that  has 
combined  aspects  of  the  Concept  Evaluation,  Demonstration  and  Validation  (DEMVAL), 
and  Full-Scale  Development  (FSD)  Phases  of  the  life  cycle.  Commencing  in  1985,  a 
draft  set  of  DON-generated  SCS  requirements  was  used  for  the  System  Design  Definition 
(SDD)  activity.  Leading  up  to  FSD  and  contract  award,  the  two  successful  bidders,  IBM 
and  General  Electric,  worked  with  the  Navy  team  to  solidify  requirements,  develop 
design  approaches,  analyze  ongoing  prototyping  efforts,  identify  critical  items,  ftne  tune 
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the  FSD  Statement  of  Work  (SOW),  and  generate  three  separate  Source  lines  of  Code 
(SLOC)  preliminary  size  estimates  for  the  AN/BSY-2  System. 

The  other  lessons  learned  on  AN/BSY-2  fall  into  six  distinct  categories:  contract, 
coordinaticm,  process,  schedule,  standards,  and  tools.  Multiple  lessons  are  presented  for 
each  of  these  areas.  Note  that  the  lessons  do  not  apply  exclusively  to  an  Ada 
devdopment  and  that  they  are  presented  randomly  within  each  cat^ory  (  i.e.,  no 
attempt  has  been  made  to  rank  them). 

Lesson  2:  Most  of  the  “lessons  teamed"  are  related  to  the  comma  requirements.  The 
SOW  should  require  regular  reports  on  the  status  of  all  commercial  products  delivered 
as  part  of  the  system.  This  update  should  include  information  such  as  vendor,  version 
number,  performance  statistics,  licensing  agreements,  and  plans  for  future  modifications. 
In  addition,  when  the  same  type  of  documentation  is  to  be  produced  by  multiple 
devdc^)ers,  implementation  of  a  standardized  style  guide  should  be  referred  to  in  the 
SOW.  Furthermore,  a  provision  should  be  included  to  allow  deliverables  to  be 
transmitted  in  an  electronic  format.  On  systems  that  have  classified  information, 
installation  and  use  of  encrypted  links  between  developer  sites  should  be  mandatory. 

To  ensure  that  requirements  flow  down  adequately,  the  prime  contractor  should  be 
required  to  provide  copies  and/or  updates  of  all  subcontract  agreements  to  the  acquisition 
agency. 

To  be  fully  effective,  software  Quality  Assurance  (QA)  should  be  totally  indq)endent  and 
organized  to  avoid  a  double  chain  of  command  (i.e.,  having  a  development  program  in 
the  place  of  corporate  QA). 

Identification,  reporting,  and  close  monitoring  of  available  metrics  should  begin  early  in 
development.  The  level  of  detail  should  increase  in  tandem  with  advanced  development. 
Metrics  should  be  analyzed  thoroughly,  and  results  should  be  incorporated  into  quarterly 
program  assessments.  Progress  or  regression  relative  to  the  program  plan  baseline 
should  be  a  key  element  in  this  assessment.  Separate  analyses  conducted  by  DON  for 
comparison  purposes  produced  additional  benefits  for  AN/BSY>2  when  results  of  these 
analyses  were  shared  with  the  developer. 

To  rasure  that  the  metrics  data  received  are  comparable  across  all  develc^ment  teams, 
a  uniform  SLCK!  counting  methodology  must  be  defined  and  followed. 

Lesson  3:  Coordination  frequemly  receives  the  least  attention  although  it  is  one  of  the 
more  importam  efforts.  Early  in  the  contract,  direct  lines  of  communication  should  be 
established  among  key  participants:  acquisition  agency,  developer,  technical  agency. 
Independent  Verification  and  Validation  (IV&V)  agency,  quality  personnel,  and  COTS 
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software  vendors.  Such  "shortcut"  communiques  result  in  more  efficient  problem 
identification  and  resolution,  which  have  an  overall  positive  effect  on  cost  and  schedule. 

Informal  networking  among  groups  of  like  interest  will  increase  the  effectiveness  of  each 
group.  Regularly  scheduled  communication  toids  to  short-circuit  problems  while 
providing  a  broader  perspective  to  participants.  For  example,  AN/BSY-2  holds  a 
monthly  user  group  meeting  to  discuss  problems,  workarounds,  and  successes  with  the 
operating  system.  The  vendor’s  active  participation  at  these  meetings  has  increased 
responsiveness  to  and  visibility  of  AN/BSY-2  needs. 

The  prime  contractor  should  maintain  tight  control  of  subcontractor  efforts  through 
weekly  monitoring  and  quarterly  audits.  Furthermore,  attendance  at  technical  and 
working  group  meetings  should  be  mandatory  for  all  team  members. 

Lesson  4:  For  large  projects,  it  is  mandatory  that  an  adequately  sized,  qualified 
Technical  Directive  Authority  (TDA)  Oversight  Group  be  established  and function  for  the 
duration  of  the  project.  Very  early  in  development,  the  contractor  should  detail  each 
process  propos^  for  use  in  the  program.  These  processes  should  be  defmed  in 
approved,  baselined  documentation.  DIDs  need  to  include  more  stringent,  detailed 
guidelines.  Multidisciplinary  contract  agency  representatives  should  then  closely  review 
each  process  in  software  development  and  in  related  areas  (configuration  management, 
QA,  testing)  for  adequacy,  consistency,  and  completeness.  Contractor  modifications  to 
these  processes  should  be  presented  during  formal  reviews  and  entered  into  the  baseline 
document  only  upon  approval. 

A  streamlined  waiver  request  process  should  be  established  for  reporting  proposed 
contract  deviations  to  language  and/or  contract  requirements.  Waiver  packages  should 
be  initiated  every  6  months,  depending  on  program  size  and  life  span. 

A  comprehensive  Ada  training  program  should  be  developed  to  address 
plication-specific  requirements.  This  program  should  be  capable  of  transitioning 
seasoned  engineers  yet  flexible  enough  to  instruct  entry-level  programmers. 

Ada  methodologies  (e.g.,  exception  handling)  should  be  defined  early  in  development. 
Partial  tasking  should  be  considered  as  an  alternative  for  reducing  rendezvous  time. 
Establishing  global  error  models  well  in  advance  of  detmled  design  will  result  in  a  more 
robust  system. 

Ada  guidelines  and  procedures  should  be  established  primarily  by  the  program’s  resident 
Ada  experts.  These  lessons  learned  should  be  provided  in  an  Ada  style  guide  as  an 
appendix  to  the  software  Standards  and  Procedures  Manual.  For  example,  compilation 
dependencies  can  be  reduced  and  debugging  smoothed  by  avoiding  subprogram  nesting. 
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This  think  tank  of  Ada  experts  should  also  be  convened  to  resolve  complex,  persistent, 
Ada  design  problems.  For  example,  enhancement  of  time-critical  prcxesses  can  be 
effected  through  expert  application  of  Rate  Monotonic  Scheduling  techniques. 

Lesson  5:  Software  development  planning  and  monitoring  must  be  done  from  the  onset 
of  FSD  and  should  take  a  phased  approach  (Le.,  “build  a  little,  test  a  little").  Ada 
software  development  schedules  should  allow  for  longer  Requirements  and  Design  Phases 
and  shorter  Test  and  Integration  Phases.  The  schedule  should  contain  Critical  Design 
Reviews  (CDRs)  to  correspond  to  the  incrementally  developed  software.  In  additicm, 
testing  should  use  manageable  units  at  phased  steps  with  explicit  success  criteria. 

The  delivery  schedule  for  software  plans,  standards,  and  procedures  should  show 
compressed  early  deliveries.  Multiple  early  deliveries  should  accelerate  establishment 
of  a  baseline.  These  planning  documents  should  be  baselined  and  under  formal 
configuration  control  no  later  than  at  the  close  of  the  Preliminary  Design  Phase. 
Conversely,  software  requirements  specifications  should  have  fewer  d^veries,  a  longer 
document  review  cycle,  and  a  baseline  before  preliminary  design. 

Product  Readiness  Reviews  (PRRs)  should  be  held  early  in  development.  These  reviews 
have  a  positive,  cohesive  effect  and  provide  a  close,  systemwide  look  at  processes, 
products,  personnel,  and  facilities.  Implementation  of  an  action  item  system  is  key  to 
PRR  effectiveness. 

The  developer  should  identify  critical-path  software  items  (e.g.,  shared  system  services). 
Close  management  of  this  process  should  ensure  early  delivery  and  test  of  these 
functions. 

Lesson  6:  Even  the  best-made  plans  require  changes  during  execution.  AN/BSY-2 
used  DOD-STD-2167A  for  software  development  guidance.  The  intent  of  this  standard, 
however,  is  to  provide  a  software  development  superset  from  which  extraneous 
requirements  can  be  eliminated.  AN/BSY-2  staff  carefully  tailored  this  standard,  mindful 
that  it  is  easier  to  provide  relief  from  requirements  than  to  "buy”  them  in  later.  The 
contracting  office  should  remain  open  to  negotiations  on  tailoring  DOD  standards  as 
phases  unfold,  technology  advances,  and/or  lessons  are  learned.  As  an  example,  support 
software  documentation  has  been  reduced  from  the  full  suite  to  design  notebroks  and 
operator  or  maintenance  manuals. 

As  part  of  tailoring  the  standards,  a  cross-check  should  be  performed  against  the  SOW. 
Checking  requirements  in  the  SOW  for  potential  ambiguities  or  even  conflicts  within  the 
military  standards  may  avoid  costly  rework  during  later  phases. 
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Lesson  7:  For  large  efforts  that  are  geographically  dispersed,  the  goal  should  be  to 
strive  for  commonality  of  development  environment,  tools,  procedures,  and  product 
structure.  The  contracting  agency  should  require  standardization  of  support  tools  across 
the  program.  Although  the  up-front  cost  is  greater,  long-term  benefits  gained  from  such 
commonality  make  it  a  worthwhile  investment.  Use  of  common  tools  allows  problems 
to  be  identiHed  and  workarounds  made  only  once  and  results  entered  into  a  shared 
electronic  reporting  system.  In  addition,  data  exchanges  among  development  teams  are 
less  time-consuming  and  more  efficient,  thus  reducing  the  risk  of  error. 

For  large  projects,  it  is  imperative  that  the  configuration  management  system  be  capable 
of  supporting  rapid  turnaround  during  the  Integration  and  Test  Phas^.  The  system 
should  provide  ccmfiguration  management  of  all  software  support  tools  as  well  as  the 
development  code.  In  addition,  a  version  control  process  must  be  established  and 
enforc^  by  the  prime  contractor  for  these  tools. 

A  common  database  should  be  established  to  electronically  track  requirements  down 
through  software  requirements  specifications  and  hardware  unit  specifications  and,  later, 
into  test.  Use  of  this  method  will  enhance  traceability  and  ensure  flowdown  of 
requirements.  A  common  database  should  also  be  created  to  track  connectivity  of 
software  interfaces.  Consistency  checks  should  be  run  for  early  detection  of  misaligned 
interfaces. 

Commercial  support  tools  may  require  modifications  to  handle  large  Ada  developments, 
and  non-Ada  commercial  code  slated  for  incorporation  into  the  product  may  create 
interface  and  performance  problems.  Additional  time  and  resources  should  be  factored 
into  development  plans  to  allow  for  these  potential  stumbling  blocks.  (Computer 
resources  should  also  be  supplemented  to  account  for  the  increase  in  demand  that 
traditionally  occurs  during  Ada  developments.) 

Compiler  benchmarks  should  be  evaluated  before  compiler  selection  is  finished. 
(Compilation  time  should  be  factored  in  as  an  additional  consideration.)  The  developer 
^ould  know  the  weaknesses  as  well  as  the  strengths  of  the  Ada  constructs  (e.g.,  link 
library  sizes  and  nesting  of  generics)  as  used  in  the  compiler  and/or  Ada  Programming 
Support  Environment  [Ada  PSE].  Binding  approaches  should  be  established  and 
benchmarked  early  in  the  development. 

Use  of  an  Ada  standards  checking  tool  is  highly  recommended.  Using  a  standards 
checker  not  only  encourages  production  of  high-quality  code  but  also  reduces  staff  efforts 
and  enhances  maintainability. 
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1.11  ADA  LANGUAGE  SYSTEM/NAVY 

The  Ada  Language  System/Navy  (ALS/N)  FSD  program  implements  Ada  for  use  with 
DON’S  standard  embedded  computers:  AN/UYK-43(V),  AN/UYK-44(V),  and  the  P3I 
AN/AYK-14(V).  Since  January  1989,  DON  has  mandated  the  use  of  ALS/N  as  the 
first-line  support  software  consideration  for  the  DON  standard  processors.  Although 
ALS/N  is  a  support  software  effort,  it  also  is  a  large  software-based  systems  development 
effort.  The  ALS/N  development  project  has  produced  more  than  1  million  lines  of  Ada 
code  that  also  support  DOD-STD-2167A  documentation. 

The  DON  Ada  Standard  Embedded  Composite  Resource  (SECR)  effort  began  in  the  early 
1980s  and  closely  monitored  the  other  Service  efforts,  such  as  the  Army  Ada  Language 
System  (ALS)  effort  and  the  Air  Force  Ada  Integrated  Environment  (AIE)  effort.  The 
DON  g(»ls  were  to  avoid  reinventing  the  wheel  and  to  maximize  the  benefits  of  the  Ada 
reuse  and  portability  concepts  for  developing  support  software.  In  1984,  DON  opted  to 
establish  the  baseline  with  the  Army  ALS  and  proceeded  to  develop  specific 
SECR-retargeted  compilers  and  tools. 

Lesson  1:  For  DON  SECR  applications,  top  priority  must  be  given  to  the  real-time 
peiformance  of  the  generated  code.  Performance  requirements  must  be  formally 
specified,  and  performance  capabilities  must  be  tested  before  product  acceptance  and 
dqrlayment,  B^use  of  the  number  and  severity  of  the  problems  encountered,  the  Army 
paid  little  attention  to  performance  issues  for  the  support  environment  and  the  targeted 
real-time  environment. 

Lesson  2:  Although  actual  software  code  production  is  only  a  relatively  snmll  portion 
of  the  total  life  cycle,  it  is  critical  to  have  a  reasonable  level  of  performance  within  the 
tool  set.  At  a  Minimum,  the  tool  set  must  meet  both  programmer  Junctional  and 
configuration  management  needs.  The  Army  ALS  tool  set  had  been  implemented  in  Ada 
but  (grated  on  the  VAX/VMS  host  environment  through  an  additional  layer  called  the 
Kernel  Ada  Programming  Support  Environment  (KAPSE).  This  arrangement  made  tool 
performance  unacceptably  slow.  The  Navy,  therefore,  redirected  the  contractor  to 
eliminate  the  KAPSE  requirement. 

Lesson  3;  Each  development  effort  should  be  managed  under  the  assumption  that  there 
will  be  a  formed  production  delivery  to  DON  and  a  separate  DON-controlled 
Post-Deployment  Phase.  To  ensure  continuous  development  oversight,  DON  laboratory 
personnel  were  provided  to  fa  tate  the  transition  to  life-cycle  support. 

Lesson  4:  Requirements  must  be  understood,  and  both  formal  and  ittformal  checks  on 
the  progress  to  meet  these  goals  must  be  conducted  throughout  development.  The  Air 
Force  used  an  independent  test  team  in  this  effort  and  spent  15%  of  the  budget  on  it. 
This  team  performed  Technical  Directive  Authority  (TDA)-type  testing  that  included  full 
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knowledge  and  understanding  of  the  product  internals.  Concurrently,  a  separate  IV&V 
agent  performed  "black  box"  testing  to  evaluate  formally  the  specified  requirements. 
Expenditures  for  this  support  were  approximately  5%  of  the  total  budget. 

Lesson  S:  Because  post-deployment  support  will  be  DON'S  responsibility,  it  is  critical 
to  build  an  adequate  in-house  team  that  is  thoroughly  familiar  with  the  product  brfore 
acceptance.  The  ALS/N  development  has  actively  funded  various  Navy  laboratories 
(e.g..  Naval  Surface  Weapons  Center  [NSWC],  Naval  Avionics  Center  [NAC],  Naval 
Undersea  Command  [NUSC],  Naval  Air  Development  Center  [NADC],  and  Naval  Ocean 
Systems  Center  [NOSC])  to  participate  in  the  program  and  also  involved  the  Navy’s 
life-cycle  agent  (i.e.,  Fleet  Combat  Direction  System  Support  ActiviQr  [FCDSSA],  ^ 
Diego). 

Lesson  6:  Lack  of  full  program  funding  commitment  and  support  will  have  a  negative 
impact  on  development  plans.  Be  prepared  to  either  alter  the  course  of  and/or  extend 
delivery  schedules.  Always  try  to  maintain  the  best  possible  product  quality  and 
maximize  life-cycle  supportability  within  the  program  constraints.  The  vagaries  of 
year-to-year  funding  support  tend  to  disrupt  large  undertakings  that  involve  many 
elements  such  as  laboratories,  prime  contractors,  subcontractors,  IV&V,  and  independent 
test  organizations.  All  parties  have  to  be  motivated,  good  informal  communication 
mechanisms  must  be  in  place,  and  all  development  efforts  must  be  carried  out  according 
to  an  agreed-to  plan  that  can  accommodate  a  certain  degree  of  flexibiliQr. 

Lesson  7:  Producing  a  high-quality  software-based  product  that  meets  its  specified 
requirements  is  a  difficult  task.  ALS/N  provides  a  software  means  to  upgrade  deployed 
SECR  processor-based  systems  indefinitely.  ALS/N  also  can  be  considered  as  the 
front-line  consideration  for  new  systems  developments  because  DON  has  100% 
ownership  or  change  control  rights.  Many  U.S.  commercial  companies  provide  Ada 
compiler  technology.  Investment  costs  for  those  technologies  that  have  been 
commercially  successful  are  consistent  with  DON  expenditures  for  ALS/N.  However, 
few  of  these  commercial  Ada  technologies  specifically  addressed  real-time  performance 
to  the  degree  of  ALS/N  capabilities,  which  is  required  for  Mission-Criti^  Computer 
Resources  (MCCR)  applications.  In  fact,  two  out  of  every  three  DON  dollars  have  been 
spent  on  DON  standard  RTE  needs.  The  ALS/N  FSD  program  has  produced  compilers 
and  run-time  operating  systems  that  will  meet  many  of  the  performance  requirements  as 
^lecified. 

Lesson  8:  No  product  is  truly  exercised  and  tested  until  it  reaches  the  target  user 
community.  It  is  best  to  phase  systems  into  deployment  through  beta  testing  and  friendly 
users  before  public  release.  Currently,  four  DON  Research  and  Development  (R&D) 
centers  use  ALS/N  in  a  test  and  evaluation  mode.  The  DON  MCCR  waiver  process  now 
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includes  ALS/N  consideration  as  part  of  the  standard  acquisition  formula  for  both  new 
starts  and  upgrades. 

1.12  AVIONICS  PROJECT 

The  avionics  project  is  a  major  system  upgrade  for  an  airborne  Command,  Control,  and 
Intelligence  (C2I)  application  that  targets  existing  platform  and  potential  forward  fit  into 
next-generation  airci^.  The  upgrade  is  to  improve  acoustic  and  nonacoustic  processing 
c^)abilities  as  well  as  signal  processing,  detection  and  classification,  multistation 
inu^rated  systems,  data  buses,  and  communications. 

Lesson  1:  Ensure  that  software  production  or  cost  modeling  includes  adequate  time  for 
die  Requirements  or  Design  Phase  before  accepting  externally  generated  completion 
dates.  The  contract  was  awarded  in  July  1987  with  a  prototype  scheduled  for  delivery 
in  July  1990.  An  optimistic  production  of  1.2  million  SLOC  is  projected. 

Lesson  2:  Be  sure  that  requirements  are  fully  defined  and  are  traceable  to  test 
mechanisms.  Include  necessary  Govemmem  visibility  into  the  process.  Beware  of 
shortcuts  and  bad  engineering  practices,  especially  when  there  is  a  prime 
contraaor-subcontractor  team  organization.  The  Firm  Fixed  Price  (FFP)  contract 
included  production  options.  The  contract  options  were  tied  to  calendar  exercise  dates, 
without  a  requirement  to  demonstrate  performance  capabilities. 

Lesson  3:  Do  not  plan  to  use  equipment  that  is  under  development  unless  absolutely 
necessary.  Apply  a  risk  engineering  approach  to  those  items  that  must  be  used,  place 
items  on  a  critical  path,  and  motutor  them  closely.  The  contract  included  the  pl^ed 
use  of  "in-development"  Government-Furnished  Equipment  (GFE)  and  Contractor- 
Furnished  Equipment  (CFE). 

Lesson  4:  Always  assume  that  everything  could  go  wrong  and  perform  full  risk 
engineering  and  management. 

Lesson  5:  Use  a  hands-on  managemeru  approach  from  both  the  prime  and  Government 
perspectives  and  delihsate  clear  lines  of  authority  and  responsibility  for  contractual 
requirements,  especially  for  large  projects.  In  addition,  do  not  take  a  hands-off  approach 
to  subcontractor  management. 

Lesson  6:  Specify  in  the  contract  requirements  that  capabilities  must  be  established 
early,  with  adequate  resources  and  autlurrity.  Closely  monitor  progress.  A  plan  must  be 
devdoped  for  handling  distributed  development  environments  and  deliverables  exchanges. 
Such  planning  must  have  been  contractually  required  and  completed,  and  it  must  receive 
some  degree  of  Government  approval  and  monitoring  before  the  program  is  executed. 
A  "sdl-ofr  from  a  subcontractor  to  the  prime  contractor  must  address  all  contingencies 
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when  the  prime  contractor-to-DON  delivery  requires  changes,  retesting  or  documoitation, 
and  the  lite.  Configuration  management  and  QA  should  be  standardized  and  coordinated 
across  the  whole  effort.  Formal,  standardized  software  development  procedures  should 
be  specified  in  the  contract  and  approved  before  being  implemented.  Lack  of  such 
formal,  standardized  procedures  cannot  be  condoned,  especiidly  across  larger  projects. 
The  procedures  should  be  monitored  to  ensure  that  the  documented  process  is  being 
implemented. 

Lesson  7:  Do  not  disregard  the  critical  elements  of  the  MIL-STDs  unless  it  is  technically 
and  managerially  necessary  to  use  alternative  means.  Develop  a  system-wide  integration 
plan  and  follow  it.  During  the  development  of  the  avionics  project  plan,  a  systemwide 
integration  plan  was  not  developed. 

Lesson  8:  Ensure  that  the  schedule  can  accommodate  slack  and  the  possibility  of 
independent  DON  test  time  for  interim  products.  Also  ensure  that  the  resources  are 
available  to  support  regression  testing.  Tlie  avionics  schedule  contains  no  plan  for  slack 
or  for  resources  to  support  regression  testing. 

Lesson  9:  Do  not  disregard  critical  MIL-STD  interim  products  in  the  contract 
requirements,  and  adequately  plan  for  and  execute  the  Government's  role  to  ensure 
quality  and  delivery.  Mutually  agre^-to  criteria  for  major  milestones  must  be  met,  or 
action  item  work  plans  must  be  created  for  unmet  criteria. 

Lesson  10;  Ensure  that  adequate  development  support  facilities  exist.  Existence  of  these 
facilities  should  be  contractually  specified  and  monitored  during  the  Produa  Redness 
Review  (PRR).  Contingency  plans  should  be  available  when  and  if  problems  develop. 
Inadequate  facility  estimates,  combined  with  no  forward-looking  projection  analysis  and 
unavailability  of  contingency  plans,  resulted  in  severe  problems  as  the  interim  product 
grew  in  size. 

Lesson  11:  Do  not  let  events  external  to  the  schedule  influence  the  program.  Develop 
input  and  output  criteria  for  major  milestones  and  adhere  to  them.  It  is  very  easy  to 
build  the  wrong  software.  During  the  avionics  project,  time  spent  in  the  Requirements 
or  Design  Phase  was  insufficient  to  mature  the  software  baseline. 

Lesson  12;  Where  possible,  use  real  production  hardware  andlor  commercial  prototypes 
to  decrease  the  amount  and  scope  of  simulation.  The  simulator  software  must  be  treated 
as  critical-path  material  if  it  is  to  be  used  during  development.  Simulator  software  also 
should  be  documented  as  operational  software  because  it  will  be  critical  when  mission 
requirements  are  being  tested.  (For  example,  the  system  may  function  in  a  simulator 
environment  but  fail  in  the  real  world.) 
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Lesson  13:  Do  not  approve  systems  until  requirements  are  met  because  u^n  system 
requirements  are  not  met  and  “as-bmlt"  systems  are  approved,  the  contractor  is  no 
longer  responsible  for  fixing  the  system.  The  system  should  not  be  sqyproved  until 
requirements  are  met.  Design  information  should  not  be  placed  in  Software 
Requirements  Specifications  (SRSs)  and  Interface  Requirements  Specifications  (IRSs). 

1.13  PEO-SSAS,  PMS-414,  SEA  LANCE 

The  SEA  LANCE  Anti-Submarine  Warfare  Stando^  Weapon  (ASWSOW)  was  being 
developed  to  provide  Vertical  Launching  System  surface  combatants  and  nuclear  power 
attack  submarines  with  a  standoff-range  missile  for  use  against  hostile  submarines. 
Before  partial  program  termination  in  December  1989,  the  program  was  in  Full-Scale 
Development  (FSD). 

SEA  LANCE  is  a  long-range  ASW  missile  system  developed  to  complement 
ship-launched  torpedoes  and  helicopter-bome  weapons  by  providing  a  quick-kill 
opportunity  at  long  ranges.  SEA  LANCE  also  can  be  launched  in  a  buoyant  protective 
cjpsule  that  floats  to  the  surface  from  a  submarine  torpedo  tube.  The  tactic^  missile 
employs  seven  embedded  processors  for  providing  guidance,  navigation,  and  flight 
control  functions.  These  tactical  processors  are  the  Guidance  Electronics  Unit  (GEU), 
which  uses  a  Motorola  68020/68881  processor;  the  Inertial  Measurement  Unit  (IMU), 
which  uses  a  Zilog  Z8002  processor;  the  Pulse  Driver  Unit  (PDU),  which  uses  an 
INTEL  8797  processor;  and  four  Fin  Actuator  Units  (FAUs),  each  of  which  uses  an 
INTEL  8797  processor.  Software  has  been  developed  under  the  guidelines  of 
DOD-STD-1679  for  each  of  these  subsystems,  the  most  extensive  development  effort 
being  for  the  Guidance,  Navigation,  and  Control  Program  (GNCP)  in  the  GEU. 

SEA  LANCE  system  software  consists  of  the  embedded  GNCP;  three  embedded  small 
systems  software  programs  (IMU,  PDU,  FAU);  two  embedded  instrumentation/flight 
termination  system  programs;  and  missile  test  set,  support,  simulation,  and 
adaptor/interface  electronics  software.  Ada  was  used  as  the  PDL  and  the  high-order 
implementation  language  only  for  the  development  of  the  GNCP.  The  following 
languages  were  used  in  all  of  the  other  SEA  LANCE  software  development  efforts: 
IMU-Z8(X)0  Assembly;  PDU-PL/M  96;  FAU-PL/M  96;  Arm  and  Control 
Unit— -PL/M  96;  Instrumentation  Data  Unit— 68020  Assembly;  missile  test  set 
software— Pascal;  support  software— Pascal,  FORTRAN,  and  Assembly;  simulation 
software— FORTRAN  and  specialized  languages.  All  discussion  and  lessons  learned  are 
concerned  only  with  the  GNCP. 

The  GNCP  is  a  digital  computer  program  totally  contained  in  nonvolatile  memory,  which 
resides  in  the  missile’s  GEU.  It  consists  of  approximately  20,000  SLOC  (100,000 
physical  SLOC).  The  GNCP  was  being  developed  in  accordance  with  the  guidelines  of 
DOD-STD-1679  using  the  VADS.  Before  program  termination,  the  GNCP  had 
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successfully  passed  through  program  milesu>nes  such  as  Preliminary  Design  Review 
(PDR)  in  August  1984,  a  Delta-PDR  in  February  1988,  an  In-Process  Review  (IPR)  in 
March  1989,  and  numerous  Technical  Interchanges  between  1983  and  1989.  Draft 
versions  of  a  test  specification,  test  plan,  and  test  procedures  were  developed  in  parallel 
to  the  design.  The  GNCP  was  developed,  test^,  and  integrated  at  the  module  and 
system  levels  in  the  contractor’s  Computer  Program  Development  L^dioratory  (CPDL), 
Operational  Mock-Up  (OMU)  Laboratory,  and  System  Integration  Laboratory  (SIL). 
Performance  and  most  preflight  testing  of  the  GNCP  was  done  in  the  SIL  to  fiilly 
nercise  es^h  function  specified  by  the  performance  specification.  The  GNCP  guided  the 
test  missiles  along  two  near-perfect  trajectories  in  the  only  two  SEA  LANCE  Ctmtractor 
Test  and  Evaluation  flight  tests  in  February  1990. 

Because  the  GNCP  had  not  yet  reached  CDR  at  the  time  of  program  termination,  DON 
never  approved  or  accepted  it.  As  part  of  the  partial  termination  efforts,  the  GNCP 
design  of  record  was  documented  in  accordance  with  DON  direction  and  archived. 

As  part  of  the  partial  termination  efforts,  a  DON/Boeing  study  is  in  process.  This  study 
shows  the  impact  of  switching  to  the  newer  defense  software  development  standards 
(DOD-STD-2167A  and  DOD-STD-2168).  The  study  is  being  conducted  in  accordance 
with  tl.e  guidelines  of  Military  Handbook  (MIL-HDBK)-287. 

Lesson  1:  Use  a  consistent  methodology  throughout  the  program  Requirements,  Design, 
and  Coding  Phases  to  facilitate  tracing  requirements  to  the  code.  SEA  LANCE  used  a 
functional  decomposition  method  in  developing  the  requirement  specifications,  then  used 
an  Object-Orient^  Design  (OOD)  methodology  when  developing  the  design  qpeciEcation 
and  the  code.  The  two  methods  had  to  be  combined.  Because  SEA  LANCE  was  a 
fire-and-forget  weapon,  the  traceability  of  every  performance  requirement  was  considered 
extremely  important.  Use  of  two  design  methods  made  it  difficult  to  trace  the 
requirements  from  the  Performance  Specification  into  the  Design  Specification  and  th«i 
into  the  code  itself. 

Lesson  2:  Use  a  common  PDL  across  the  projea.  On  medium-  to  large-scale  systems, 
die  PDL  will  contain  a  wide  variety  of  differing  coding  techniques  and  codefragments. 
SEA  LANCE  used  Ada  as  its  PDL.  It  was  learned  that  when  Ada  was  used  as  a  PDL, 
the  software  development  and  uniform  coding  standards  should  be  enforced  on  the  PDL 
as  well  as  on  the  actual  Ada  code. 

Lesson  3:  Include  and  enforce  a  requiremem  for  a  minimum  ratio  of  50/50 
comments-to-code  in  the  contract,  software  developmem plan,  or  coding  guide.  Although 
Ada  is  more  readable  than  many  other  languages,  it  still  requires  a  liberal  use  of 
comments  to  describe  what  is  going  on  and  why.  Generally,  Government  code  reviewers 
needed  more  review  time  because  of  the  lack  of  comments. 
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Lesson  4:  Use  an  automated  format  utility  or  equivalent  software  tool  to  ensure  untform 
code  appearance.  This  can  be  imposed  through  either  QA  or  configuration  management. 
The  LANCE  contractor  did  not  always  use  a  printer  format  utility  or  other 
automated  tools  to  ensure  uniform  appearance  of  the  code.  As  a  result,  many  Ada 
specifications  and  bodies  had  a  unique  appearance,  depending  upon  the  individual  t^er. 

Lesson  5:  Develop  a  style  guideline  for  the  Ada  code  and  PDL  before  doing  any  design 
work.  The  SEA  LANCE  contractor  developed  most  of  the  PDL  without  a  formalized 
Ada  coding  guideline.  The  result  was  a  PDL  that  sometimes  differed  from  module  to 
module  in  tqppearance,  style,  and  coding  format. 

Lesson  6:  Use  software  metrics  from  the  beginning  and  define  basic  terminology  between 
Ada  and  the  selected  software  development  standard.  The  minimal  use  of  software 
metric  tools  and  the  defining  of  basic  terms  in  the  early  development  process  gave  rise 
to  conflicts  between  the  contractor  and  the  Government  as  to  what  constituted  a  module, 
a  line  of  code,  or  the  difference  between  a  PDL  line  of  code  and  an  operational  line  of 
code. 

Lesson  7:  Hammer  out  documentation  requirements  and  licensing  agreements  between 
the  Government  and  the  coruractors  regarding  the  use  of  third-party  software  and  the  way 
it  is  to  be  tested  and  identified.  The  SEA  LANCE  contractor  employed  a  proprietary 
third'party  ARTX,  and  the  Government  had  trouble  obtaining  documentation  on  the  inner 
workings  and  testing  of  the  Run  Time  Executive  software. 

Lesson  8:  Early  in  the  development  process,  have  the  contractor  provide  a  detailed  list 
of  tools  that  will  be  used  in  the  development  process  for  the  PDL/code  and  specify  the 
format  that  will  be  used  for  transfer  of  source  code,  executable  code,  and  software 
documentation  to  the  Government.  (Note  that  DOD-STD-1679  did  not  reqmre  a 
Computer  Resource  Integrated  Software  Documem  fCRISDJ.)  The  Government  h^  some 
difficulty  finding  compatible  computers  to  load  in  contractor-transferred  software  listings. 
It  also  proved  difficult  to  identify  the  exact  format  of  software  deliverables  and  the  exact 
configurations  of  the  contractor-used  development  tools. 

1.14  NAVY  WORLD  WIDE  MILITARY  COMMAND  AND  CONTROL  SYSTEM 
(WWMCCS)  SITE-UNIQUE  SOFTWARE  (NWSUS)  PROJECT  MISSION 

Lesson  1:  It  is  always  safer  to  build  and  test  incrememally.  Space  and  Naval  Warfare 
Systems  Command  (SPA WAR)  PMW  161-5  is  responsible  for  modernizing  eight  existing 
site-unique  COBOL  1968  applications  with  approximately  300,000  lines  of  Ada  source 
code  on  the  NWSUS  project.  These  applications  arc  operational  on  the  WWMCCS 
Honeywell  DPS8  mainframe  and  are  being  reengineered  using  Ada  (X)D  with 
DOD-STD-2167A  because  Honeywell  is  phasing  out  msuntenance  of  COBOL  1968.  This 


Ada  Implemantation  Guide 


1-51 


Lessons  Learned 


is  within  the  WWMCCS  Automatic  Data  Processing  (ADP)  Modernization  (WAM) 
Program.  The  NWSUS  project,  which  is  divided  into  three  increments,  is  in  the  third 
year  of  a  S-year  effort.  The  first  increment  consists  of  six  smaller  ^plications  vdth  the 
larger  plications  in  the  later  increments. 

Lesson  2:  Planning  for  and  designing  in  reuse  yield  long-term  benefits.  The  project  is 
in  accordance  with  DOD-STD-2 167 A/2168  tailored  for  OOD.  The  existing  COBOL 
plications  are  used  to  capture  requirements.  Development  is  performed  on  a  Rational 
R-1000  model  40  with  Honeywell  DPS8  and  IBM  PC/XT  clones  as  targets.  With  one 
excq)tion,  the  applications  are  Management  Information  Systems  (MISs),  and  the 
development  makes  extensive  use  of  a  common  set  of  reuse  components. . 

Lesson  3:  For  large  software  undertakings,  use  of  automated  tools  is  mandatory.  The 
2167A  documentation  is  being  developed  on  the  Rational,  and  a  Computer-Aided 
Software  Engineering  (CASE)  tool  has  l^n  developed  to  validate  the  completeness  and 
consistency  of  the  requirements,  design,  object/class  specifications,  and  Ada 
specifications.  Two  "4GL-like'‘  productivity  tools,  used  in  conjunction  with  the  reuse 
components  to  create  application  screens  and  reports,  are  used  for  rapid  prototyping  and 
to  support  the  generation  and  standardization  of  the  user  interface. 

Lesson  4:  Until  the  design  baseline  has  been  approved  and  frozen,  it  is  inadvisable  to 
initiate  full-blown  coding.  An  initial  CDR  was  completed  for  Increment  1  in  April  1990, 
and  a  second  CDR  to  review  redesign  caused  by  a  change  of  target  was  conducted  later. 
Development  of  many  of  the  reuse  components  was  completed.  Full  development  of  the 
Increment  1  Configuration  Items  (CIs)  began  and  was  completed  in  FY92. 

A  full  Object-Oriented  Requirements  Analysis  (OORA)  and  specification  for  the 
Increment  2  CIs  were  completed  at  the  System  Design  Review  (SDR),  which  was  very 
successful.  Both  the  site  customer  and  SPA  WAR  commented  on  the  effectiveness  of 
OORA.  The  CDR  occurred  in  October  1991. 

Lesson  5:  If  a  risk  engineering  approach  (I.e.,  awareness,  identification,  technical 
management  of  alternative  solutions)  is  taken  to  development,  then  it  is  possible  to 
undertake  technologically  challenging  developments.  Conventional  wisdom  says  that  a 
project  with  a  new  application  area,  a  new  programming  language,  or  new  personnel  will 
have  trouble.  NWSUS  had  all  three;  consequently,  the  project  has  had  its  share  of 
problems.  The  problems  spanned  development  methodology  and  standards,  target 
development  environment  (both  Ada  compiler  problems  and  problems  with  the 
compiler/operating  system  bindings),  Ada  training  and  startup,  software  reuse,  contract 
structure,  and  management.  However,  NWSUS  has  managed  to  survive  these  problems 
and  is  currently  in  a  productive  mode. 
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The  following  lists  some  of  the  problems  encountered  and  their  solutions  or 
workarminds. 


Pkoblem 

Ada  compiler  was  unavailable  for 
HoneyweU  DPS8,  and  WWMCCS 
Information  System  (WIS)  Workstation 
target  was  unavailable  at  contract  start. 

Functicmal  analysis  was  requited  for  the 
first  increment. 


The  contract  assumed  that  all  CIs  were 
the  same,  and  a  hard  split  between 
design  and  code  hindered  Ada  CX)D. 


Contract  and  management  of  reuse 
between  applications  initially  was  weak 
and/or  missing. 


DPS8  Ada  compiler  was  late  and  not 
mature;  the  Workstation  was 

canceled. 


Initial  training  was  affected  by  the 
■3-week  syndrome." 


Resolution 

The  Rational  was  selected  as  the  host 
development  envinmment  for  all 
applications.  Testing  is  first  done  on  the 
Rational  and  then  on  the  target. 

The  functional  analysis  ^roach  did  not 
work  out  well.  Full  (^ject-  oriented 
analysis  was  used  for  the  seccmd 
increment,  and  that  approach  has  been 
very  beneficial. 


The  contract  structure  was  modified  to 
reflect  the  diversity  of  the  CIs  and  the 
R&D  nature  of  the  project  and  to  allow 
an  efficient  mechanism  for  reuse 
components  and  prototyping. 

An  internal  approach  was  used  to 
support  reuse  on  a  level-of-efTort  Work 
Breakdown  Structure  (WBS).  DON 
recognized  the  need  in  the  contract 
update. 

The  workstation  target  was  changed  to  a 
PC.  Redesign  is  under  way  for  the  new 
target  and  for  a  solution  of  the  problems 
encountered  with  the  DPS8  Ada 
compiler. 

Initial  training  was  too  compressed  and 
not  project  q)ecific.  NWSUS  now  uses 
a  p^-time,  2-month,  in-house  training 
seminar  with  a  "lab  session"  that  uses 
project  deliverables. 
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OOD  proved  to  be  labor  intensive  during 
the  fint  increment. 


Ada  OOD  proved  to  be  a  vay  effective 
development  approach  because  it  gives 
much  more  visibility  and  ccmtrol  of  the 
analysis  and  design.  The  drawback  is 
that  this  requires  much  more  effort.  We 
found  no  available  CASE  tools  that 
supported  it,  and  too  much  had  to  be 
done  manually.  The  validation  process 
was  automated  for  the  second  increment. 


I.1S  EVENT-DRIVEN  LANGUAGE/COBOL-TO-Ada  CONVERSION 
PROGRAM 

From  1987  to  1989,  the  Marine  Corps  replaced  its  aging  inventory  of  ruggedized  IBM 
Series-l  minicomputers  with  hardened  IBM-compatible  microcomputers.  The  transition 
required  that  all  of  the  systems  originally  programmed  for  execution  on  the  Series- 1  be 
ported  to  the  microcomputer.  Approximately  25  systems  were  written  in  Event-Driven 
Language  (EDL)  or  COBOL.  At  about  the  same  time,  Ada  was  introduced  as  the 
standard  programming  language  for  DOD.  The  close  proximity  of  the  two  events 
provided  the  Marine  Corps  with  an  opportunity  to  gain  valuable  expertise  in  the  new 
DOD  standard  programming  language  through  reverse  ongineering  of  well-known 
systems.  At  the  time,  the  Marine  Corps  had  no  in-house  Ada  programmers  and  no 
expertise  in  its  associated  design  methodologies. 

The  rq)rogramming  effort  was  divided  among  three  Marine  Corps  Central  Design 
Programming  Activities  (CDPAs)  along  fimctional  boundaries.  In  the  process  of  the 
rq)rogtamming  effort,  the  Marine  Corps  learned  several  lessons. 

Lesson  1:  Training  is  essential  for  both  technical  and  management  personnel.  To  take 
full  advantage  of  Ada,  designers  and  analysts  must  be  familiar  with  the  principles  of 
software  engineering  and  the  way  Ada  supports  those  principles.  Because  few  Marines 
had  knowledge  of  Ada  design  methodologies  at  the  outset,  the  tendency  was  to  recode 
the  original  system  designs  in  Ada.  The  original  system  designs  were  often  derived 
directly  from  the  existing  EDL/COBOL  code.  Because  neither  of  those  languages 
contains  all  of  the  Ada  constructs,  the  advantages  of  Ada  did  not  always  materialize. 

Lesson  2:  Programmers  require  4  to  9  months  oftrcamng  before  they  become  proficient. 
It  takes  4  to  9  months  of  formal  and  on-the-job  training  before  a  programmer  b^mes 
proricimt  in  Ada.  However,  after  that  initial  training  period,  the  programmer  should  be 
C2q>able  of  producing  code  very  r^idly  whoi  given  a  good  design  and  programming 
library. 


1-54 


Department  of  the  Navy 


LMSOnt  LMTIMd 


Lesson  3:  Military  tranters  often  result  in  a  loss  of  investment  in  Ada  training. 
Because  profici«ncy  in  Ada  can  take  as  much  as  9  months  to  attain,  a  newly  trained 
programmer  is  productive  only  for  a  portitxi  of  his  or  her  tour.  Unless  stq)s  ate  taken 
to  ensure  reassignment  to  anoAer  Ada  shop,  the  training  investmoit  is  likely  to  be  lost. 

Lesson  4:  Systems  originally  written  in  languages  that  predate  Ada  that  must  be 
converted  to  Ada  should  be  redesigned,  not  translated.  After  the  first  few  projects,  it 
was  evidoit  that  inefficiencies  in  the  original  designs  w^  being  duplicated  in  the  Ada 
translations. 

Lesson  5:  Ada  facilitates  reuse.  During  the  conversion  effort  and  on  subsequent 
projects,  the  Marine  Corps  found  that  on  an  avmage  project,  only  4S%  of  the  code  had 
to  be  writtra  from  scratch;  the  other  55%  came  from  reuse.  Reusable  code  generally 
came  from  previous  projects  and  developmoit  tools  (e.g.,  AdaSAGE).  In  recent 
projects,  the  Marine  Corps  has  consulted  Ada  software  rqwsitories  for  reusable  code  in 
an  effort  to  reduce  development  time  and  effort  wherever  possible. 

Lesson  6:  Ada  lends  itself  to  ^ciera  code  and  high  programmer  productivity.  The 
syntactical  structure  of  Ada  helped  the  Marine  Corps  implement  many  of  the  software 
oigineering  principles.  Modularity,  information  hiding,  localization,  and  abstraction 
were  easily  implemented. 

Lesson  7:  Development  tools  are  essential.  Initially,  lack  of  a  good  tool  kit  hindered 
the  conversion  effort.  In-house  tools  were  built  to  overcome  Ada  file  limitations  and  to 
enhance  scteoi  management.  Shortly  thoeafter,  the  Marine  Corps  funded  the 
development  of  AdaSAGE,  which  reduc^  development  time  by  as  much  as  50%. 

Lesson  8:  Development  and  maintenance  time  can  be  significantly  reduced  by  applying 
software  engineering  principles  and  ctqfitalmng  on  reuse.  The  Marine  Corps  estimates 
that  from  15%  to  ^%  r^ucdon  in  devdopment  and  maintenance  time  are  being 
achieved  when  software  engineering  principles  and  reuse  are  applied. 

1.16  SHIPBOARD  GRIDLOCK  SYSTEM  WITH  AUTO-CORRELATION 
The  Shipboard  Gridlock  System  with  Auto-Correlation  (SGS/AC)  plication  plays  a 
fundamental  role  in  the  coordination  of  multiplatform  shipboard  systems  by  processing 
the  ships’  data  and  remote  track  data  within  a  common  positional  frame  of  reference. 
This  application  performs  gridlock  processing  to  correct  for  sensor  and  navigational 
errors  while  correlating  the  identified  tracks  from  remote  systems.  This  software-based 
plication  is  characterized  by  hard  deadlines;  multiple  external  interfaces;  and 
time-critical,  computationally  intrasive  processing.  The  SGS/AC  is  dqrloyed  on  the 
Aegis  cruiser/destroyer  class  of  surface  ships. 
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Lesson  1:  B^ore  commtmem  is  made  to  large  projects,  the  methods  and  tools  to  be 
used  should  be  exercised.  Quantitative  evaluation  of  the  expended  resources  should  lead 
to  better  estimates  for  the  work  contemplated.  This  project  is  being  performed  by  the 
Naval  Surface  Warfare  Center  (NAVSWC).  It  can  be  characterized  as  a  DEMVAL 
development  effort  that  parallels  the  SGS/ AC  program  implemented  in  CMS-2  for  either 
the  ANAJYK-20(V)  or  the  AN/UYK-44(V)  t^et  processors.  This  parallel  effort  uses 
ALS/N  as  the  host  development  tool  set  and  targets  an  AN/uyK-44(V)  processor 
configuration.  An  additional  objective  of  the  effort  is  to  genoute  a  comprehensive 
comparative  analysis  of  the  CMS-2  and  Ada  developments  that  includes  quantitative  data 
and  information  pertinent  to  future  Aegis-class  combat  direction  system  upgrades. 

Lesson  2:  The  Ada  code  itself  will  have  mtgor  architectural  and  design  impaa  on  a 
system;  therefore,  the  two  must  be  worked  on  simultaneously.  From  the  outset,  it  was 
recognized  that  to  simply  translate  CMS-2  code  to  Ada  would  be  technically  feasible  but 
would  not  produce  any  long-term  benefit. 

Lesson  3:  A  project  should  always  try  to  build  a  little  and  test  a  little,  building  and 
testing  the  harder  things  first  (e.g.,  system  services  and  communications).  The  new 
design  effort  attempted  to  minimize  the  run-time  overtiead,  include  portability  in  the 
design,  manage  intofaces  to  get  best-case  req)onse  under  worst-case  loads,  and  maximize 
robustness  and  predictability.  A  multiphased  build  plan  was  initiated. 

Lesson  4:  A  project  should  always  attenqrt  to  involve  the  production  hardware  as  early 
in  the  program  as  feasible.  Success  simulator  and  emulator  runs  mean  nothing  when 
the  delivered  code  does  not  work  on  the  real  hardware.  Acceptance  requirements  must 
be  set  correctly,  or  development  stdiedule  reserve  must  be  allocated  to  absorb  such 
difficulty.  Things  will  go  wrong,  and  this  should  be  anticipated.  /  development  is 
being  carried  out  on  VAXs,  with  DEC  Ada  being  used  during  the  ea^  Jode  and  Test 
Phases.  The  target  AN/UYK-44(V)  processor  requires  special  cards  to  run  the  Ada 
code.  The  particular  configuration  was  unavailable  until  well  into  the  project. 

Lesson  5:  The  team  must  be  well  trained  in  the  use  of  the  supplied  tools,  and  the  tools 
must  work  as  advertised.  The  ability  to  fully  define  a  working  set  of  integrated  tools 
early  in  development  and  to  acquire  them  as  they  are  needed  is  critical.  For  example, 
a  symbolic  debugger  is  an  absolute  necessity. 

Lesson  6:  Adherertce  to  good  engineering  practices  is  necessary  when  designing  the 
system  and  its  hardware  and  software,  ^though  this  project  is  a  relatively  small 
software  undertaking,  establishing  and  enforcing  sound  software  design  methodology  and 
development  processes,  such  as  coding  standards,  documentation  production,  and  code 
reviews,  help  overcome  l^ses  in  memory,  personnel  turnover,  lack  of  focus,  and  lack 
of  requirements  to  trace  verified  design  or  <^e. 
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Lesson  7:  Until  more  technological  progress  is  achieved,  the  potential  for  large-scale 
software  component  reuse  is  limited.  This  project  has  shown  that  achieving  real-time 
developments  requires  meeting  hard  deadlines  and  getting  close  to  the  target  machine, 
which  often  conflicts  with  the  concept  of  code  component  reuse. 

1.17  SUBMARINE  COMBAT  CONTROL  SYSTEM  MK2 
The  Submarine  Combat  Control  System  (SCCS)  Program  focuses  on  consolidating  the 
various  Combat  Control  and  Defensive  Weapon  Systems  (DWSs)  software  configurati(ms 
that  are  in  use  on  deployed  SSN-688  and  SSN-726  class  submarines.  These  vessels 
constitute  both  the  defensive  (attack)  and  strategic  platforms  for  the  DON  submarine 
force.  The  SCCS  upgrade  will  either  upgrade  or  replace  obsolete  general-purpose 
computers,  peripherals,  display  consoles,  and  weaqnns  simulators.  This  software 
upgrade  provides  a  common  software  package  for  both  classes  of  submarine  and 
incorporates  operational  and  maintoiance-related  mhancements.  The  SCCS  Program  also 
includes  the  development  of  systems  to  support  crew  training  and  land-based  testing. 

The  software  for  the  SCCS  consists  of  new  development  software  and  firmware, 
modified  Government-Furnished  Software  (GFS)  and  firmware,  and  unmodified 
commercial  software  and  firmware. 


Most  of  the  modified  GFS  software  has  been  written  in  either  DON-standard  CMS-2 
HOL  or  in  ULTRA-32  Assembly.  The  project  mission  is  to  develop  a  maintenance 
C2q)ability  that  improves  the  chances  for  coordinating  evolutionary  change  in  these 
shipboard  systems. 


The  new  portion  of  the  SCCS  MK2  program  involves  integrating  a  replacement 
human-computer  interface  display  console  and  associated  Ada  ^>plication  software  into 
the  existing  deployed  systems.  The  approximate  language  mix  is  as  follows: 


Language 

CMS-2  &  ULTRA-32 

Ada 

C 

FORTRAN 


SLOC 

2M  (GFS/modified) 
58  IK  (new) 

279K  (commercial) 
149K  (retained) 


The  Ada  SJ.OC  are  being  developed  under  DOD-STD-2167A  requirements.  The 
CMS-2,  FORTRAN,  and  ULTRA-32  software  were  all  developed  under  DOD-STD- 
1679A. 


The  paragraphs  below  summarize  the  lessons  learned  about  Ada  on  this  project. 


Ada  Implementation  Guide 


1-57 


Ltssons  LMm«d 


Lesson  1:  Ada  experience  and  training  are  needed.  The  majority  of  experimced 
personnel  in  this  defense  area  had  little  or  no  experience  with  Ada  and  modem  software 
engineering  practices.  It  was  necessary  to  evaluate  bidders  (mi  their  in-plaoe  Ada 
expertise  and  on  their  ability  and/or  plans  to  acquire  or  build  on  that  base.  To  properly 
monitor  or  manage  the  development,  in-house  csqiabilities  had  to  be  built  up  in  th^ 
areas.  It  is  especially  important  to  use  hands-on  training  as  close  to  development  as 
possible  or  during  development. 

The  relative  immaturity  of  candidate  Ada  products,  coupled  with  the  specific  need  to 
handle  many  foreign  language  interfacing  requirements,  meant  that  the  developer  team 
needed  a  very  close  relationship  with  their  candidate  Ada  development  tool  suppliers. 

Lesson  2:  Siqtpon  software,  practices,  and  products  need  constant  attention.  This 
undertaking  required  that  the  chosen  contractor  be  caq)able  of  using  automated  tools  to 
manage  and  technically  execute  this  large  programming  development.  To  that  end, 
source  selection  criteria  were  established  and  used  during  the  source  selection  process. 

Each  project  has  to  generate  its  own  Computer  Resources  Life-Cycle  Management  Plan 
(CRLCMP)  and  Integrated  Logistics  Support  Plan  (ILSP)  before  the  Defmse  Acquisition 
Board  (DAB)  Milestone  I.  However,  unless  the  Government  defines  the  total 
development  environment  fiilly  and  requires  its  use  as  part  of  the  proposal,  difficulty  vdll 
ensue  as  differences  develop  l^tween  the  methodology,  tools,  and  equipment  used  by  the 
developer  and  those  specified  by  the  Program  Office.  Typically,  the  parties  involved  wUl 
have  opposing  agendas.  Coupled  with  the  inability  of  many  tools  to  scale  up  to 
programming-in-the-large  or  even  to  exchange  data  structures  efficiently,  this  diversity 
will  create  problems  that  all  parties  will  need  to  address  and  work  out  on  a  continuing 
basis.  Examples  of  areas  where  this  problem  resolution  may  be  required  include  tool 
standardization;  data  exchange;  version  mam^ement;  electronic  communication;  data 
rights;  documentation  uniformity;  configuration  management;  error  identification, 
analysis,  and  elimination;  product  ownership;  component  integration;  and  testing. 

Lesson  3:  The  need  to  interface  with  other  language  programs  may  constrain  the  type 
of  Ada  features  that  can  be  used.  The  Ada  language  design  run-time  concq>t  does  not 
map  directly  to  the  hard  real-time  environment  within  the  MK2  system.  Therefore, 
attempts  must  be  made  to  overlay  the  Ada  model  on  top  of  the  inherited  real-time 
operating  system,  which  has  necessitated  eliminating  certain  Ada  features  (e.g.,  tasking). 
OthCT  Ada  features  not  used  include  generics,  dynamic  allocation,  and  full-range  data 
typing.  Performance  also  has  suffered,  and  portability  has  been  minimized.  The  need 
to  interface  with  other  language  programs  may  result  in  a  loss  of  the  advantages  of  strong 
Ada  typing  and  may  affect  debugging,  testing,  certification,  and  the  like. 
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Lesson  4:  To  ensure  programming  uniformity,  a  style  guide  should  be  developed  and 
used  acrtm  all  developer  teams.  Use  of  a  common  style  guide  will  enhance  overall 
maintainability  of  developed  code.  It  also  will  help  control  Ada  feature  utilization,  and 
the  code  can  be  automatically  checked  by  applying  a  preprocess  tool.  The  use  of  a 
"pretty  printer"  posQirocessing  mechanism  for  human-readable  ou^uts  could  also  enhance 
softw^  maint^nability. 

1.18  P-3C  UPDATE  IV  Ada  DEVELOPMENT 

The  objective  of  the  P-3C  UPDATE  IV  Program  is  to  develop  a  fully  integrated, 
distributive  bus,  data  processing  system  with  improved  mission  avionics  systems.  The 
full  weapon  system  is  to  be  tailored  for  both  retrofit  into  P-3C  predecessor  aircraft  and 
forward  fit  into  successor  Maritime  Patrol  Aircraft.  The  program  successfully 
progressed  through  the  DEMVAL  Phase  between  November  1984  and  April  1987.  After 
the  Milestone  n  decision  in  July  1987,  Boeing  was  awarded  an  FFP  contract  for  FSD  to 
develop  and  fd)ricate  the  system,  qualify  vendors,  install  the  system  into  a  P-3C 
platform,  and  conduct  vendor  flight  tests  by  July  1990.  The  schedule  called  for 
Government  testing  of  the  flying  test  bed  between  July  1990  and  February  1992  with 
subsequent  aj^roval  for  full  production  to  be  granted  in  April  1992. 

The  program  includes  the  distributive  bus  data  processing  Distributed  Processor/Display 
Generator  Unit  (DP/DGU)  system,  which  consists  of  six  Motorola  68020-based  processor 
modules/DGUs  tied  together  by  a  dual  15S3B  bus  architecture.  Major  mission  systems 
avionics  include  the  ANAJYS-2  acoustic  processor,  the  Motorola  68020-based 
AN/ALR-66(V)  S  Electronic  Support  Measures  (ESM)  system,  and  the  AN/APS-137  (V) 
3  Inverse  Synthetic  Apoture  Radar.  The  data  processing  system  and  ESM  are  CFE,  and 
the  acoustic  processor  and  the  radar  are  GFE. 

The  program  has  been  delayed  by  both  hardware  and  software  development  difficulties. 
Boeing  was  expected  to  deliver  Ae  flying  test  bed  to  the  Government  between  October 
1992  and  February  1993. 

As  one  of  the  first  large  Ada  develqpmrats  (over  1  million  SLOG),  the  P-3C  Update  IV 
program  has  been  a  pioneer  in  the  use  of  Ada.  Boeing  personnel  have  made  several 
correct  choices  in  developing  software  in  a  new  programming  language  for  which  the 
software  development  environment  was  immature  or  Umited.  First,  Boeing’s  choice  of 
using  the  VADS  was  a  good  one.  VERDDC  has  been  a  leado^  in  the  development  of  Ada 
software  engineering  tools,  and  VADS  was  one  of  the  best  Ada  software  development 
environments  available  at  the  time  of  program  initiation.  Equally  good  was  the  choice 
of  the  Ready  Systems  kernel  as  the  core  for  the  operating  system.  Finally,  Boeing’s 
naming  convention  for  Top  Level  and  Lower  Levd  Computer  Software  Components 
(TLCSCs/LLCSCs),  packages,  units,  and  identifim  has  also  been  beneficial.  The 
naming  convention  has  bem  very  useful  in  tracing  requirements  to  design  and  code  and 
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is  hdpfiii  when  reading  the  PDL  and  computer  source  code.  The  paragraphs  below 
summarize  the  lessens  learned  about  Ada  use  in  this  program. 

Lesson  1:  Ada  code  requires  mote  iqhfrom  time  and  qffon,  and  the  learning  curve  is 
slower.  The  software  size  and  develppmoit  schedule  estimates  were  understated  by  all 
parties  during  the  initial  phase  of  the  program,  llie  table  bdow  lists  SLOC  estimates  at 
program  initiatien,  at  completion  of  PDR,  and  in  August  1991. 

The  final  SLOC  total  should  exceed  August  1990  estimates  by  more  than  10%  before 
completion  of  software  devdopment.  The  initial  sizing  estimates  will  be  in  error  by 
appiDximatdy  100%  at  program  conq)letion. 

The  Boeing  estimates  for  the  software  devdopment  schedule  were  predicated  on  available 
non-Ada  HOL  usage.  Individual  task  estimates  were  too  short  and  did  not  antidpate  the 
increased  up-front  work  in  Ada  design  and  coding  that  was  needed.  This  fact  and  a 
slower  than  antidpated  learning  curve  for  coders  resulted  in  a  realized  progress  rate  of 
8S%  of  plan  for  coding,  testing,  and  integration  activities. 

Lesson  2:  Increasedfadlities  and  memory  are  required  to  accommodate  Ada  code.  The 
physical  number  of  hardware  tools  was  iititially  insuffident  to  support  a  software 
devdopment  of  this  magnitude.  This  lack  of  hardware  csqKidty  was  experienced  in  all 
areas  of  the  software  development  aivizonnu^:.,  from  the  Sun  workstations  used  during 
initial  code  and  testing  to  the  System  Avionics  Integration  Laboratory  (SAIL)  used  for 
system  int^ration.  More  Sun  workstations  woe  needed  to  avoid  bottlenecks  in  coding, 
both  in  the  SDL  and  at  tiie  subvendOT  locations  involved  in  tactics  and  corrdatiem 
programming  efforts.  The  Boeing  SDL  grew  from  two  Sim  3/280  server  stations  with 
33  Sun  clioit  workstations  in  the  ftdl  of  1987  to  five  Sun  3/280  server  stations  with  45 
Sun  clioit  workstations  in  the  fall  of  1990. 

The  SDL  mainftames  used  for  the  target  hardware  software  build  process  could  not 
construct  a  software  build  in  an  accqitable  period.  Initial  software  program  builds  took 
up  to  1  wedc  to  compile  and  link.  The  SDL  initially  contained  one  VAX  11/785,  one 
VAX  11/750,  and  two  VAX  87(X)s.  To  accommodate  the  software  development 
demands,  the  SDL  was  upgraded  by  the  fall  of  1990  to  include  one  VAX  11/785,  one 
VAX  11/750,  two  VAX  6000/440s,  and  one  VAX  8600.  Disk  storage  capacity  was  also 
increased  to  sqiproximatdy  40  gigabytes  (GB).  This  increase  in  hardware  capacity  has 
reduced  system  build  time  to  approximately  8  hours. 

Initial  plans  called  for  target  int^ration  to  be  conducted  on  a  single  SAIL  that  contained 
as  much  actual  UPDATE  IV  hardware  as  possible,  including  the  full  DP/DGU  system. 
A  DON  SAIL  was  held  at  Bodng  instead  of  bang  ddivered  to  DON  to  accommodate 
the  effect  of  the  integration  overload  on  the  Bodng  SAIL. 
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Software 

CoafigurafioB 

ItamfCSCI) 

Beet  aad  Final 
OffierfBAFO) 

(April  1M7) 

1 

1 

Ai«iietl991 

DPADGU 

3S3,530 

468,654 

565,431 

MmimumMode 

Softweie(MMS) 

0 

37,900 

52,764 

Eketfooic  S«9poft 
Meosttie  (ESM) 

S2.340 

58,000 

55,516 

Acouatic  fialerfroe 
UaitCAIU) 

6S.900 

68,900 

97,371 

AN/tJYS-2 

37,320 

38,000 

147,500 

Syatem  Avknice 
bitegntian 

Labontofy  (SAIL) 

218,600 

172,870 

211,766 

bilegntiaa  Teat 
SoftwateCTTS) 

S,000 

96,900 

109,359 

Software 

Devdopawnt 

Laboratoiy  (SDL) 
(Boeiiig- 
Devdoped  Code 

Only) 

37,300 

45,500 

62,800 

TOTAL 

803,190 

986,724 

1,302407 

Les5<m3:  Seme  scftwande^kU/pmentwob  an  inumntn  and  ha^  not  been  proven  far 
many  (qtpUcadons,  Tmmatuii^  and/or  unavailability  of  software  development  tools  also 
complicated  eariy  software  devdopment  efforts.  A  comprehenave  Ada  siqiport 
environment  was  unavailable  for  early  devdopment  woric.  Available  tools  were 
immature  and  were  not  int^rated  into  a  comprehenave  padoge.  In  addition,  available 
tools  were  very  resource  intensive,  ^diich  exacerbated  the  previoudy  mentioned  hardware 
problems. 
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The  Sun  workstation  software  build  installations  initially  required  1  week  and  ccmtained 
numerous  errors  because  of  excessive  operator  intervention.  Upgraded  Sun  workstation 
software  and  software  tool/automation  development  resulted  in  eventual  turnaround  times 
of  1  day.  Error  reduction  was  excellent  as  a  result  of  the  automated  tools. 

The  initial  SDL  VAX  systems  woe  plagued  with  software  and  hardware  faults,  which 
resulted  in  numerous  system  crashes  and  an  average  downtime  of  1/2  day  per  week.  By 
aqiplying  pressure  to  Digital  Equipment  Corporation,  fixes  were  put  in  place  ovcx  a 
peii^  of  1  year,  which  resulted  in  mature,  s^le  system  performance. 

The  VERDDC  compiler  was  selected  for  use  aftm-  available  compilers  were  screened  by 
the  procedures  recommended  in  1987.  However,  numoous  early  software  and  hardware 
errors  were  encountered  before  stable  performance  was  achieved.  As  late  as  January 
1991,  the  VERDDC  Ada  compiler  with  the  verson  6.0  program  was  found  to  have  an 
optimizer  error.  After  the  compiler  was  corrected,  the  UPDATE  IV  program  required 
a  total  recompile  to  remove  inefficiencies  scattered  throughout. 

Lesson  4:  Tailoring  of  DOD  software  development  standards  must  be  addressed  to 
accommodate  Ada-unique  capabilities.  Although  DOD-STD-2167A  does  not  require  that 
software  development  efforts  follow  the  traditicmal  waterfall  model  associated  with  DOD 
software  developmoits,  it  does  not  provide  guidance  on  alternatives.  Ada  forces  more 
detailed  design  earlier  in  the  software  developmoits  than  do  previous  languages  because 
of  the  Ada  package  specifications  and  the  strong  data  types  imposed  by  Ada.  These 
factors  encourage  a  pseudo  "rapid  prototyping*  sqiproach  rather  than  the  traditional 
waterfall  during  the  design  phas^. 

DOD-STD-2167A  does  not  address  distributed  processor  systems  or  multiple  Cl 
developments.  Ada  was  designed  specifically  for  a  modular  approach  to  large  software 
developments.  For  example,  DOD-STD'2167A  does  not  adequatdy  address  testing 
among  multiple  CIs  or  the  Integration  Phase  issues.  DOD-STD-2167A  documentation 
neither  reflects  Ada  terminology  or  structure  nor  addresses  an  spprppriate  approach  to 
documentation  devdopment. 

Lesson  5:  Although  the  adoption  cf  Ada  was  envisioned  to  enhance  the  software 
development  process,  use  of  Ada  does  not  guarantee  sound  software  engineering  practice. 
Specific  areas  where  Ada  does  not  substitute  for  sound  engineering  practices  include; 

•  Establishmeru  of  system  and  software  requirements.  A  Requirements  Analysis 
Phase  must  be  conducted  to  produce  ^ropriate  system-level  requirements  that  are 
thoi  allocated  to  hardware  and/or  sofbvare  as  appropriate.  Partcipation  by  both 
contractor  and  Government  systems  engineoing  personnel  throughout  this 
evolution  is  critical  to  program  success. 
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•  Er^Tcement  of  control  points.  The  contract  must  require  and  the  Govemntent 
must  enforce  a  variety  of  control  points.  These  control  points  must  take  into 
account  Ada-unique  development  a^yproaches  where  the  approach  differs  from  the 
traditional  DOD-STD-2167A  waterfall  model.  Allowing  the  con^tor  to  proceed 
past  these  control  points,  even  if  he  does  so  "at  risk,"  imposes  significant  risk  on 
successful  program  completion. 

•  Corfigurasion  management.  Use  of  Ada  does  not  preclude  GovOTiment 
requirements  for  establishing  and  controlling  the  fimcticMial,  allocated,  and  product 
t»affiiTif^  Use  of  Ada  may  complicate  control  of  the  software  allocated  basdine 
by  inviting  inclusion  of  design  detail  into  the  software  requirements  documents. 
Although  Ada  forces  more  detailed  design  earlier  in  the  software  developmrat 
process,  the  temptation  to  include  this  detail  into  the  software  allocated  baselme 
must  be  avoided. 

•  Testing.  The  mapping  of  Ada  constructs  to  DOD-S'ID-2167A  "umts,"  "modules, 
and  "system"  is  imprecise  and  can  lead  to  inadequate  testing  of  Ada  code.  The 
DOD-STD-2167A  premise  of  fully  qualifying  a  software  entity  at  one  level  of 
abstraction  before  combining  that  entity  into  larger  integrated  components  should 
be  maintained.  A  software  entity  should  not  be  considered  fully  qualified  soldy 
because  the  higher-level  entity  into  which  it  is  incorporated  successfully  passes  its 
qualification  requirements. 

T.^>!S!Bnn  6:  Strict  corfiguration  management  and  control  are  required  to  etforce  discipline 
to  counter  complexity-induced  corfusion.  Lack  of  frunilianty  with  Ada,  a  slow  learning 
curve  for  new  coders,  and  schedule  delays  reemphasize  the  ^solute  r^uirement  to 
maintain  Strict  softwaie  and  hardware  control  within  all  facilities.  With  differing  levels 
of  coding,  unit  and  package  testing,  informal  int^rabon  testing,  and  formal  systems 
te^titig  occurring  in  the  respective  facilities,'  strict  configuration  management  within  the 
freilities  and  within  the  software  development  library  was  mandated.  The  Gov«nment 
the  initial  Software  Devclopmmit  Folders  (SDFs)  and  found  them  deficient. 
Replication  of  numerous  informal  tests  wuld  not  be  accomplished  from  the  SDFs,  as 
written. 

1.19  STANDARD  FINANCIAL  SYSTEM  REDESIGN 

The  Standard  Financial  System  (STANFINS)  is  part  of  the  total  U.S.  Army  accounting 
system  and  serves  as  a  field-level  system  for  gennal  funds  servicing  posts,  camps,  and 
stations.  The  original  STANFINS  was  a  batch  processing  system  written  in  COBOL. 
A  STANFINS  Redesign  project  (STANFINS-R)  was  undertaken  to  ovwhaul  the  system 
and  make  it  interactive. 
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STANFINS-R  consists  of  two  subsystems— Subsystems  I  and  n— to  be  develq)ed 
indqiendently.  This  large  system  is  designed  to  handle  mainstream  accounting 
j^licatimis  sudi  as  the  gene^  ledger,  accounts  receivable,  fixed  assets,  and  cost 
accounting  standards.  The  system  consists  of 500  programs  with  ^>proximately  2  millimi 
lines  of  code,  and  it  generates  147  rq»its.  The  cmtract  for  devdoping  Subsystem  n, 
which  otiginadly  was  viewed  as  a  large  COBOL  project,  was  awarded  to  the  Computer 
Sdences  Corporatitm  (CSC)  in  the  fall  of  1986.  However,  the  contract  was  modified  in 
the  firing  of  1988,  and  Ada  was  designated  as  tiie  devdopment  language.  The  first  pilot 
teams  were  formed  in  the  spring  of  1988,  and  the  actual  writing  of  code  and  Ada 
bindings  b^an  in  the  M  of  1988.  Software  devdopment  testing  and  software 
qualificatitm  testing  started  in  the  summer  and  ftdl  of  1989,  reqrectivdy.  Most  of  the 
system  tests  have  been  completed,  and  part  of  the  project  is  operational. 

The  project  was  devdoped  in  an  automated  program  support  oivironmoit  composed  of 
six  Rational  R-1000  machines.  The  code  was  eventually  ported  to  the  targd 
environment,  an  IBM  mainframe  running  OSA^MS. 

Despite  delays  in  the  implementation  schedule  and  budgd  m'emins,  the  STANFINS-R 
project  indicates  that  there  are  several  advantages  to  using  Ada  in  informaticm  systems 
devdopment.  For  example,  programmer  productivity  has  been  quite  high  (594  lines  of 
code  per  staff  month),  almost  double  that  of  tyjncal  COBOL  projects,  and  ^  quality  of 
the  software,  as  evidenced  by  the  test  results,  appears  to  be  uniformly  high. 

In  many  ways,  STANFINS-R  is  a  prototypical  information  systems  project  from  which 
many  lessons,  including  those  described  bdow,  can  be  learned  about  Ada  use. 

Lesson  1:  The  available  pool  of  developers  skilled  in  Ada  is  limited.  When  making 
projections  about  project  costs,  the  issue  of  the  limited  number  of  available  personnd 
skilled  in  Ada  and  the  need  for  training  should  be  considered.  STANFINS-R  originally 
was  conceived  as  a  COBOL  project.  When  denial  of  the  waiver  resulted  in  a  switch  to 
Ada  as  the  devdopment  language,  it  became  a^rparent  that  the  available  pool  of 
developers  with  Ada/MIS  experience  was  small.  The  existing  staff  of  COBOL 
programmers  had  to  be  trained  in  Ada,  which  caused  delay  in  project  execution. 

Lesson  2:  Few  compilers  and  support  tools  are  available  for  irformation  systems 
deveUtpment  in  the  IBM  environments  that  use  Ada.  STANFINS-R  demonstrated  that 
Ada  is  a  viable  language  for  devdoping  information  systems  in  environments  where 
COBOL  has  beat  the  dominant  developmoit  language.  However,  the  IBM  environment, 
which  is  the  primary  environment  for  devdoping  such  systems,  is  poorly  supported  in 
terms  of  compilers  and  support  tools.  STANFINS-R  was  the  first  Ada  application  of  its 
kind  and  size  to  be  devdoped  to  run  on  an  IBM  OS/VMS  environmoit.  Because  of  the 
lack  of  available  tools  to  support  Ada  in  this  oivironment,  a  set  of  suj^rt  tools,  such 
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as  code  generators  and  screm  painters,  had  to  be  developed  as  part  of  the  project. 
Moreova,  the  compiler,  which  was  developed  by  Intermetrics  but  had  not  been 
validated,  did  not  provide  support  for  a  Cl-based  telq)rocessing  mmiitor;  therefore,  the 
contractor  had  to  write  one.  In  addition,  the  DBMS  package  chosen  for  the  project  (i.e., 
Datacom  DB)  did  not  contain  a  suitable  Ada  interface;  therefore,  a  hook  had  to  be 
written.  For  Ada  to  be  a  feasible  language  for  use  in  developing  information  systems, 
the  issue  of  availability  of  compilers  and  suppcnt  tools  must  be  addressed.  Most  Ada 
vendors  do  not  offo’  products  in  this  enviitmment.  The  dominant  compiler  in  this 
envmmmoit  (offered  by  Intermetrics)  has  not  been  validated.  The  unavailability  of 
suitable  comi^ers  has  been  a  significant  ff^ctor  inhibiting  the  use  of  Ada  in  information 
systems  and  has  created  an  adverse  cycle  of  events.  On  the  one  hand,  because  Ada  is 
not  the  preferred  language  in  informaticm  system  development,  vendors  have  little 
incentive  to  offer  products  to  work  on  the  platforms  (m  which  such  applications  are 
traditionally  developed.  On  the  other  hand,  the  paucity  of  suitable  products  works  to 
limit  the  consideration  of  Ada  in  developing  information  systems.  Successful 
implementation  of  the  mandate  to  use  Ada  will  require  a  suitable  resolution  of  this  cycle. 
A  plausible  way  to  address  this  problem  would  be  to  create  2q>propriate  incentive 
structures  that  will  encourage  vendors  to  devdpp  such  products. 

Lesson  3:  Systems  develop^  in  Ada  may  be  more  maintainable  than  those  written  in 
COBOL.  Although  it  is  too  early  to  state  definitively  that  Ada  maintraance  requirements 
are  lower  than  those  for  COBOL,  preliminary  evidence  indicates  this  may  be  so.  Part 
of  STANFINS  is  operational  and  Im  a  maintenance  staff  of  six  programmers,  a  much 
smaller  team  than  would  be  required  to  maintain  a  system  of  similar  size  that  uses 
COBOL. 

Lesson  4:  In  principle,  portability  is  ensured  by  developing  code  in  Ada;  however,  in 
practice,  portability  is  limited.  Porting  the  code  from  the  Rational  oivironment  to  the 
target  environment  was  problematic.  For  a  variety  of  reasons,  parts  of  the  code  that 
worked  well  on  the  Rational  environment  did  not  work  in  the  target  oivironment.  For 
example,  nested  generics  would  not  work  on  the  target  although  they  tested  and  compiled 
on  the  development  machine.  Executable  code  ^raring  could  not  be  implemented  on  the 
target,  ther.^y  causing  the  executable  sizes  to  grow  to  unmanageable  proportions.  Otheu- 
features,  such  as  rqnesentation  specifications,  Unchecked_Conversion,  and  Pragma 
Inline,  were  not  implemented  in  the  target  compilo’. 

Developers  in  this  prqjea  had  significant  problems  with  porting  code  from  the 
development  envircmment  to  the  target  environment.  What  compiled  on  the  Rational  R- 
KXX)  also  compiled  on  the  IBM  mainfiame  using  OS/MVS.  However,  lack  of  compiler 
siqrport  for  the  tdqnocessing  monitor  and  intofaces  to  the  DBMS  necessitated  the 
creation  of  low-levd  functionally  limited  code,  therd)y  limiting  portability  to  other 
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environments  without  significant  modifications.  Thus,  while  most  of  the  code  can  be 
ported  to  a  VAXA^S  environment,  for  example,  complete  portability  would  require 
significant  alterations. 

Lesscm  5:  Ada  has  special  advantages  that  make  reuse  more  feasible  and  enables  die 
ben^  of  reuse  to  be  redial  at  several  levels.  At  one  level  are  qjedfic  packages  and 
templates  diat  can  be  used  in  other  parts  of  the  i^oject  or  in  other  projects.  While  the 
same  could,  in  principle,  be  accomplished  with  code  written  in  COBOL,  the  use  of 
generics  and  parVagfig  gives  Ada  a  q)ecial  advantage  over  COBOL  diat  makes  sudi  reuse 
much  more  feasible.  There  was  significant  use  of  these  templates  at  STANFINS.  The 
issue  of  reuse  can  also  be  viewed  in  terms  of  tools  that  are  developed  for  specific 
projects  but  with  suitable  modificaticxis  can  be  used  in  other  projects.  The  STANFINS 
project,  for  example,  entailed  the  develq>ment  of  Program  Structure  Language 
(PSL)/Program  Structure  Analysis  (PSA)  tools  for  writing  design  ^deifications.  These 
tools  can  plausibly  be  modilKed  and  reused  in  other  projects.  A  follow-up  project,  the 
Standard  Army  Financial  Accounting  and  Rqxnting  System  (STARFIARS),  d^onstrates 
reusability  at  both  levels.  Although  STARITARS  is  likely  to  be  at  least  33%  larger  than 
STANFINS,  the  project  is  scheduled  to  take  S0%  less  time  than  STANFINS.  The 
rationale  for  this  fast-paced  schedule  is  twofold:  STANFINS  provided  a  useful  learning 
curve  from  which  STARFIARS  will  benefit,  and  more  important,  the  implmnentation  of 
STANFINS  has  created  system  templates  and  tools  that  can  be  reused  to  create  the  new 
system  with  greater  productivity. 

Lesson  6:  Tailoring  of  DOD  software  development  standards  must  be  addressed  to 
accommodate  Ada-unique  capabilities.  The  documoitation  required  for  STANFINS-R, 
which  was  prqnred  according  to  the  requirements  mandated  in  AIS  DOD-STD-793S-A, 
was  inordinately  large.  While  the  exact  figure  is  difficult  to  ascertain,  a  cmiservative 
estimate  is  that  every  line  of  code  generated  at  least  10  lines  of  documentation.  The 
voluminous  documentation  clearly  limits  its  usefulness  and  points  to  the  need  to 
reexamine  current  documoitation  standards. 

1.20  RECONnGlJRABLE  MISSION  COMPUTER  FRO JECT 
The  Reconfigurable  Mission  Computer  (RMQ  Project  sought  to  demonstrate  that 
modularity  in  both  hardware  and  software  would  reduce  the  cost  of  developing  new  or 
upgrading  existing  embedded  systems.  The  thrust  of  the  project  was  to  exploit  hardware 
and  software  commonality  in  Afferent  embedded  systems. 

Lesson  1:  For  small  technology  demonstration  projects,  anticipate  a  lade  of  Ada 
compilers  for  small,  embedded  computers  that  use  advanced  microprocessors.  Primary 
constraints  on  mis^e  goieral-purpose  data  processors  are  size,  power,  and  cycles  per 
second.  There  is  always  a  drive  to  use  die  most  advanced  microprocessors  available  to 
get  as  mudi  performance  as  possible  in  as  small  a  space  as  possible  while  consuming  the 
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least  power  possible.  Ada  compiler  vendors,  however,  are  not  going  to  market  a 
compilo^  until  they  can  determine  that  it  is  financially  realistic  to  do  so.  Small 
technology  demonstrations  that  want  to  use  Ada  in  the  software  development  may  be 
restricted  to  using  processors  for  which  a  commercial  Ada  compiler  exists. 

Lesson  2:  Plan  on  allocating  a  portion  of  the  CPU  utilization  to  the  imfficiencies  of 
using  a  modular  design  approach  and  design  implementation  in  Ada.  The  RMC  project 
goals  included  creating  portable  Ada  programs,  running  them  on  several  platforms, 
measuring  the  code  change  required,  and  learning  what  it  took  to  make  an  Ada  program 
portable.  A  modular  design  based  on  Abstract  Data  Types  was  used  to  hide  machine 
interfuses.  We  also  hid  the  "goodies”  the  compiler  vmidors  offered  outside  of  the  Ada 
language  behind  our  own  package  interfaces.  The  results  were  a  reduction  in 
performance  that  can  be  made  up  with  a  highm*  throughput  CPU.  However,  any 
throughput  increase  realized  by  upgrading  platforms  is  usually  given  to  the  analyst  to 
develop  more  capable  algorithms.  A  modular  design  in  Ada  can  reduce  code,  test,  and 
modification  times  and  is  well  worth  the  extra  overhead  incurred. 

Lesson  3:  Plan  on  throwing  away  some  or  all  of  the  first  software  designed.  After  the 
first  design  and  implementation  of  demonstration  software  in  Ada,  it  was  felt  that  the 
implementation  would  be  improved  the  next  time.  Fortunately,  we  had  the  luxury  of 
doing  just  that,  and  we  understood  and  implemmited  a  much  better  software  system  the 
second  time.  It  is  not  necessary  to  wait  until  all  of  the  tools  and  hardware  are  in  place 
to  begin  coding.  As  much  of  the  design  as  possible  should  be  implemented  as  soon  as 
possible.  A  commercial  prototype  or  similar  system  should  be  used  to  gain 
understanding  of  the  system,  and  the  first  cut  should  be  used  to  verify  that  the 
requirements  can  be  met. 

Lesson  4:  Dedicate  an  individual  or  group  (depending  on  the  size  of  the  project)  to  the 
Ada-hardware  interface.  Ada  touches  the  "iron"  in  several  places:  the  target  debug 
monitor  for  on-target  program  development;  the  kmnd  for  time,  memory,  and  processor 
management;  and  device  drivers  used  by  the  application.  A  person  or  group  needs  to  be 
familiar  with  hardware  registers,  ports,  memory  locations,  and  the  low-level  facilities 
available  in  Ada.  Evolving  hardware  architectures  and  compilm’  upgrades  make  this  an 
absolute  necessity. 

1.21  INTELUGENT  MISSILE  PROJECT 

The  purpose  of  this  project,  which  is  funded  by  the  Office  of  Naval  Technology  under 
the  Missile  Support  Technology  block  NW2A,  is  to  develop  generic  software  techniques 
and  to  design  tools  that  will  allow  the  use  of  knowledge-based  Artificial  Intelligence  (AI) 
paradigms  for  control  and  decision-making  functions  in  nussUes.  These  capabilities  are 
to  be  implemented  in  Ada.  Having  these  features  will  yield  more  adaptive  and 
autonomous  missile  qreration. 
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A  simple,  forward-chaining  inference  engine  was  developed  and  tested  on  several 
computers.  Next,  a  decision-tree  type  of  expert  system  was  developed  along  with  a  tool 
(in  Ada)  to  generate  the  Ada  decision  tree.  (None  of  the  commercial  expert  system 
shells  could  do  this  at  the  time.)  Finally,  a  hybrid  system  was  developed  that  combined 
the  flexibility  of  an  inference  engine  with  the  sp^  of  a  decision  tree.  Execution 
performance  was  measured  for  all  three  types  of  systems.  The  decision  tree  was  the 
fastest,  and  the  hybrid  system  was  a  close  second. 

Lesson  1:  System  analysis  must  be  conduct^  at  the  beginning  to  ensure  that  adequate 
resources  (e.g.,  conqrilers,  hardware  platform)  mil  be  available  for  meeting  the  system 
requirements.  The  tendency  to  favor  particular  hardware  or  cortqyiler  systems  Just 
because  they  are  available  must  be  avoided.  Choosing  a  particular  CPU  simply  because 
it  is  available  can  lead  to  problems  that  could  have  bera  avoided  by  performing  adequate 
system  analysis.  One  problem  encountered  was  that  the  CPU  needed  an  Assembly 
program  to  be  downloaded  and  run  to  "Idckstart*  the  CPU  so  that  Ada  code  could  be 
downloaded  and  executed.  The  CPU  was  hardwired  to  have  a  certain  memory 
configuration  that  was  incompatible  with  the  mandatory  location  of  the  Ada  code. 

Similarly,  using  a  compiler  that  already  is  on  hand  without  ensuring  it  can  do  the  job  also 
will  lead  to  delays.  In  this  case,  the  compiler  had  been  validated  for  a  particular  single¬ 
board  computer.  Although  the  vendor  stided  that  it  should  work  with  the  chosen  target 
board,  the  vendor  would  not  provide  any  help  because  compilers  for  other  CPUs  had  a 
much  higher  priority.  This  happened  in  spite  of  the  faa  that  the  highest  level  of 
maintenance  available  had  been  purchased  for  this  project. 

Lesson  2:  Although  Ada  has  many  features,  it  does  not  have  every  feature  from  every 
language;  for  exanqtle,  Ada  is  restriaed  in  the  type  of  A1  systems  for  which  it  can  be 
used.  Because  it  is  a  procedural  language,  Ada  has  some  restrictions,  particularly  with 
regard  to  certain  AI  applications.  In  LISP,  an  arbitrary  string  of  characters  can  be 
handled  in  three  different  ways;  as  text,  as  a  variable,  or  as  a  function  to  be  called. 
This  ability,  which  is  very  useful  for  building  production-type  expert  systems,  results 
from  LISP’S  being  not  only  a  language  but  also  an  oivironment.  Because  Ada  is  only 
a  language,  there  are  restrictions  on  the  types  of  production  expert  systems  that  can  be 
implemented.  Although  it  would  be  possible  to  implement  the  equivalent  LISP 
environment  in  Ada,  LISP  is  too  slow  and  big  for  a  missile  system,  which  was  the  reason 
for  its  not  being  used  in  the  first  place. 
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FY91  Ada  Technology  Insertion  Program  Projects 

This  appendix  provides  a  brief  description  of  the  Ada  Technology  Insertion  Program 
(ATIP)  projects  funded  in  FY91.  The  projects  fall  into  three  primary 
categories— education,  bindings,  and  technology.  For  more  information  on  these 
projects,  contact  the  Ada  Joint  Program  Office  at  (7Q3)  614-0209. 

J.1  EDUCATION 

Of  the  14  projects  funded,  one  addresses  Ada  education.  It  is  the  "Undergraduate 
Curriculum  and  Course  Development  in  Software"  given  by  the  Advanced  Research 
Projects  Agency  (ARPA). 

This  program  will  support  the  development  of  educational  materials  using  Ada  that 
will  be  widely  distributed  to  and  used  by  educators.  It  will  enhance  the  software 
engineering  content  of  courses  and  course  sequences  in  computer  science  curricula 
and  wiU  demonstrate,  through  pilot  implementations,  the  feasibility  and  viability  of 
a  comprehensive  undergraduate  curric^um  in  software  engineering  using  Ada. 

JJ  BINDINGS 

The  eight  bindings  projects  are  grouped  into  the  following  categories: 

•  Government  Open  Systems  Interconnection  Profile  (GOSIP) 

•  Management  Information  System  (MK)  Mathematical  Binding 

•  MiUtaiy  Standard  (MIL.STD)-1553 

•  Portable  Operating  System  Interface  for  UNIX  (POSDC) 

•  Structured  Query  Language  (SQL) 

•  XWindows. 

Ada  Application  Program  Interface  to  GOSIP  Network  Services 
Defense  Information  Systems  Agency  (DISA)  (Formerly  DCA) 

GOSIP  is  a  family  of  protocols  that  supports  network  services.  Althou^  Ada 
bindings  to  GOSIP  exist,  this  project  will  develop  a  robust  Ada/GOSIP  binding  for 
standardizing  the  interface  of  Ada  applications  to  GOSIP  network  services. 

Decimal  Arithmetic 
U.S.  Air  Force 

Compiler  vendors  support  decimal  arithmetic  but  in  nonstandard  ways.  This  project 
will  standardize  a  mechanism  for  realizing  (X)B01^style  exact  decimal  arithmetic  in 
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Ada  83.  It  will  provide  sufficient  functionality  to  handle  financial  applications  with 
at  least  18  digits  of  precision.  It  will  offer  early  availability  with  Ada  83  compilers, 
notational  convenience,  ease  of  transition  to  Ada  9X,  and  run-time  efficiency. 

Generic  Avionics  Data  Bus  Toolkit 
U.S.  Navy 

This  project  will  offer  a  standard  software  interface  that  can  be  reused  for  various 
Mn^STD  multiplex  data  buses  with  minimal  changes.  The  initial  software  will  focus 
on  the  MIL-STD-1SS3B  protocol  because  this  protocol  is  the  most  prevalent,  but  it 
will  be  designed  to  be  configured  for  expansion  to  other  types  of  data  buses.  An 
integrated  MIL-STD-1SS3B  monitor  with  debugging  tools  is  planned. 

POSIX/Ada  Real-Time  Bindings 
U.S.  Air  Force/Navy 

POSIX  defines  a  collection  of  system  services  that  provide  portable  application 
interfaces  to  operating  systems.  The  POSIX  effort  is  divided  into  several  areas  that 
cover  the  range  of  operating  system  services.  These  include  basic  system  services, 
real-time  services,  security  services,  user  command  interface,  user  graphical  interface, 
network  services,  mail  services,  and  system  administration.  This  project  will  develop 
draft  Ada  bindings  for  the  real-time  service  area  (POSIX  1003.4  and  1003.4a 
standards),  work  with  the  Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 
standards  organization  to  promote  the  use  of  these  drafts  as  a  starting  point  for 
development  of  standard  Ada  bindings,  and  develop  a  test  protore  implementation 
of  Ada  tasking  using  the  1003.4  (real-time)  and  1003.4a  (threads)  services. 

Ada  SQL  Interface  Standardization 

Defense  Advanced  Research  Projects  Agen^  (DARPA) 

SQL  is  a  set  of  standards  associated  with  relational  databases  and  data  dictionaries. 
The  SQL  Ada  Module  Description  Language  (SAMeDL)  provides  an  interface 
technology  for  Ada  applications  accessing  SQL  database  management  systems 
(DBMSs).  The  ATIP  ^1  fully  document  both  the  SAMeDL  as  a  language  and  its 
supporting  methodology,  respond  to  the  needs  of  the  standardization  process,  and 
coordinate  efforts  of  potential  vendors  of  SAMeDL  processors  as  weU  as  identify 
needs  of  potential  SAMeDL  customers  to  assist  the  transition  to  the  SAMeDL. 
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A  SAMeDL  Pilot  Project  on  SIDPERS-3 
U.S.  Air  Force/Army 

A  SAMeDL  tool  set  will  be  developed  consisting  of  a  SAMeDL  Module  Manager 
and  a  SAMeDL  compiler.  These  tools  will  target  a  designated  database  running  on 
an  Everex  Personal  ^mputer  (PC)  under  UNDC  Both  an  existing  application  and 
a  new  application  will  be  developed  using  this  tool  set.  This  effort  is  designed  to 
prove  that  the  SAMeDL  tool  set  has  the  robustness,  maturiQr,  and  potential  for 
reusability  to  be  employed  as  the  Ada/SQL  binding  of  choice  on  any  large 
Department  of  Defense  (DOD),  Ada  Management  Information  System  (MIS) 
program. 

Common  Ada  XWindow  Interface 
U.S.  Navy 

XWindows  is  zde  facto  industry  standard  that  provides  a  Graphical  User  Inter&ce 
(GUI).  Popular  tooUdt  extensions  to  XWindows  include  Open  Look  (used  AT&T, 
Sun,  and  others)  and  Open  Software  Foundation  (OSF)  Motif  (used  by  IBM,  Digital 
Equipment  Corporation,  Hewlett-Packard,  Apollo,  and  others).  This  project  will 
design  and  produce  a  Common  Ada  XWindow  Interface  (CAXI)  to  both  the  Open 
Look  and  Motif  toolkits.  The  interface  will  be  written  in  Ada  and  will  allow 
application  programs  to  use  either  toolkit  without  modification  to  the  application 
program.  This  will  increase  the  portability  of  Ada  applications  and  provide  flexibility 
in  the  selection  of  hardware. 

An  Interactive  Ada/XWindows  User  Interface  Generator 
U.S.  Army 

This  project  proposes  to  develop  a  general-purpose  Ada/XWindows  User  Interface 
Generator  that  automatically  generates  Ada  source  code.  Using  this  tool,  a 
developer  will  be  able  to  interactively  develop  a  functioning  user  interface  Ity 
selecting  user  interface  primitives  and  arranging  them  on  the  screen.  This  tool  is 
intended  to  reduce  the  bottleneck  imposed  upon  Ada  tystems  developers  when 
developing  window-based  user  interfaces  based  on  the  XWindows  system  and  the 
Motif  toolkit 

JJ  TECHNOLOGY 

The  five  projects  in  the  technology  category  deal  with  the  following: 

•  Engineering  environments 

•  Prototyping 
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•  Reuse 

•  Security. 

AdaSAGE  Enhancements 
U.S.  Air  Forcc/Amty/Navy 

AdaSAGE  is  an  applications  development  set  of  utilities  designed  to  facilitate  rapid 
and  professional  construction  of  systems  in  Ada.  The  Department  of  Energy 
developed  AdaSAGE  at  the  Idaho  National  Engineering  Laboratory.  .^)plications 
may  vary  from  small  to  large  multiprogram  ^tems  using  special  capabilities.  These 
ci^abilities  include  database  storage  and  retrieval  (SQL  compliant),  gn^hics, 
communications,  formatted  windows,  on-line  help,  sorting,  and  editing.  Ada^GE 
operates  on  various  ^tems  including  MS-DOS  platforms,  UNIX  System  V,  and 
OS/2.  A  developer  using  the  Ada  language  and  the  AdaSAGE  development  ^tem 
can  design  a  product  tailored  to  a  specific  requirement  that  offers  outstanding 
performance  and  flexibility.  The  ATIP  proposal  provides  enhancements  to 
AdaSAGE  requested  by  the  user  community  and  supports  the  creation  of  a 
computer-aided  training  program. 

ATLAS/Ada-Based  Enhancements  for  Test  (ABET) 

U.S.  Air  Force 

ABET  is  an  Air  Force  and  IEEE  effort  to  provide  an  international  standard  for  an 
automatic  test  environment  for  maintenance  activities.  Ada  is  the  language  to  be 
used  for  implementing  this  standard.  ABET  will  intelligently  incorporate  Ada  into 
the  test  arena  by  providing  a  set  of  layered  standards  to  the  test  community. 

A  Computer-Aided  Prototyping  System  for  Real-Time  Software 
U.S.  Air  Force 

The  program  will  demonstrate  a  high-technology,  low-cost  approach  to  providing  the 
latest  software  prototyping  tools  for  real-time  Ada  programs.  It  provides  the 
opportunity  to  use  the  thesis  efforts  of  students  at  the  Naval  Postgraduate  School, 
who  are  DOD  personnel  familiar  with  Ada  and  its  embedded  !q)plications. 

Reusable  Ada  Products  for  Information  Systems  Development  (RAPID) 

U.S.  Army 

RAPID  is  an  Ada  reuse  program  that  indudes  an  automated  library  tool  for 
configuration,  identification,  and  retrieval  of  reusable  Ada  software  conqronents  and 
a  staff  that  supports  and  trains  developers  in  reusability  and  sound  software 
engineering  prindples.  Its  mission  is  to  ensure  that  the  DOD  objective  of  reusable. 
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maintainable,  and  reliable  Ada  software  is  achieved.  It  provides  a  total  reuse 
program  supporting  the  entire  software  development  life. 

Ada  Reuse  in  a  Trusted  Message  Processing  System  for  ReaMlme  Software 
U.S.  Navy 

This  project  will  investigate  Ada  reuse  in  developing  software  that  satisfies  the 
Orange  Book  B2-Level  security  requirement.  The  system  will  be  fielded  as  the 
Submarine  Message  Buffer  (SMB)  System,  supporting  personnel  with  two  levels  of 
security  clearance. 
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Appendix  K 

Navy  and  Marine  Corps  Ada  Projects 

A  database  of  Navy  and  Marine  Corps  projects  that  use  Ada  has  been  assembled  for 
r^crence  by  Program  Managers  who  are  planning  to  use  or  currently  are  using  Ada. 
The  database  includes  the  following  information: 

•  Project  Name 

•  Project  Description 

•  Application  Area,  (i.e.,  Command  and  Control  [C2],  Command,  Control  and 
Communications  [C3],  Command,  Control,  Communications,  Computers,  and 
Intelligence  [C4I],  Electronic  Warfare  [EW],  Space,  Communication,  Armament, 
Ordnance,  Acoustic,  Navigation,  Financial,  Personnel,  Contracting,  Material 
Management,  Medical,  Depot  Maintenance,  Tool,  Database  Management  System 
[DBMS],  Gri^hical,  Education,  Simulation,  Other) 

•  Spmisor/Developer 

•  Point  of  Contact  and  Phone  Number 

•  Program  Status  (in  planning,  developed,  completed,  or  canceled) 

•  Source  Lines  of  Code  (SLOC) 

•  Host  System 

•  Target  System. 

Because  this  database  is  very  large,  its  contents  have  not  been  included  in  this  vernon  ■ 
of  die  Ada  Implememasion  Guide.  It  is  available  either  on  disk  as  a  Lotus  1-2-3  file  or 
in  hard  copy.  To  obtain  a  copy,  please  fill  out  the  attached  order  form. 

If  you  would  like  your  project  to  be  considered  for  inclusion  in  this  database,  please 
provide  the  information  listed  on  the  order  form. 
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ORDER  FORM 

Program  Name 
Prog.  Manago* 
Address 

City,  St  &  Zip 

Please  send: 

(1) 

Copy  of  DON  Ada  Projects  Database  on  disk  (Lotus  1-2-3 

File)  and/or 

(1) 

Hard  copy  of  DON  Ada  Projects  Database 

To  have  your  project  considered  for  inclunon  in  this  database,  please  provide 
the  following  information; 

• 

Project  Name 

• 

Project  Description  (brief  &  concise) 

• 

Application  Area,  (i.e.,  C2,  C3,  C4I,  EW,  Space, 
Communication,  Armament,  Ordnance,  Acoustic, 

Navigation,  Financial,  Poaonnel,  Contracting,  Material 
Management,  Medical,  Dqwt  M^tenance,  Tool,  DBMS, 
Graphical,  Education,  Simulation,  Other) 

• 

Sponsor/Developer 

• 

Point  of  Contact  and  Phone  Number 

• 

Program  Status  (in  planning,  developed,  completed,  or 
canceled) 

• 

Source  Lines  of  Code  (SLOC) 

• 

Host  System 

• 

Target  System. 

Please  send  this  order  form  and/or  project  information  to: 

Space  &  Naval  Warfare  Systems  Command 

SPAWAR  3241  (CDR  M.  Romeo) 

2451  Crystal  Drive  (CPK-5,  700) 

Washington,  DC  20363-5208 

Ada  Implamantation  Quids 
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Appendix  L 

Ada  Language  Features  That  Support  Software 
Engineering 


Ada  has  several  features  that  directly  support  software  engineering.  This  appendix 

discusses  in  great  technical  detaU  those  features  that  are  amsidcred  important,  including 

Ada  packages,  strong  typing,  exceptions,  generics,  Ada  library  (sqarate  compilation), 
and  tasking. 

Many  people  consider  the  Ada  package  to  be  the  most  important  featim  m  ^  language 
to  support  the  goals  and  principles  of  software  engineering.  Hence,  it  is  a  primary 
in  producing  software  that  is  reliable,  of  high  quality,  within  budget,  and  on  schedule. 

The  Ada  par»ifag#>  consists  of  two  parts:  a  package  specification  and  a  package  body. 
The  specification  identifies  "what“  the  package  is  going  to  do;  the  package  body 

the  “how"  and  provides  implementation  details  of  the  code  hidden  ftomAe 
appiirariftn  The  package  specification  identifies  how  any  Ada  application  can  interface 
with  the  package.  In  a  sense,  the  package  qiecification  is  a  legal  contract  with  Ada 
iqjplications.  The  package  body  contains  the  code  to  conduct  the  real  work  of  die 
As  Figure  L-1  depicts,  an  Ada  sq^licatimi  must  go  through  the  pacl^e 
in  order  to  benefit  from  the  code  in  the  body.  The  specification  identifies 
the  only  way  that  an  Ada  implication  can  interftice  with  the  package  body. 

Typically,  an  Ada  application  is  a  main  program  with  a  collection  of  ^kages. 
Attachment  1  to  this  appmidix  contains  a  sample  of  an  Ada  package  qiecification.  This 
sanqilc  provides  an  abstraction  of  the  parcel. 

Once  appropriate  abstractions  are  created  with  the  package  feature,  the  abs&actions 
be  used  by  the  main  Ada  program  or  other  packages.  Attachment  2  to  this  ^^(fix, 
which  uses  a  queue  example,  provides  a  simple  example  of  a  complete  package  with  boto 
die  paciragg  specification  and  the  package  body.  The  parcel  abstraction  package  is 
imported  for  use  in  the  queue  example. 

These  examples  of  packages  demonstrate  all  of  the  software  engineering  principles: 
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Figure  L*l.  Ada  Package 


•  Abstraction.  The  package  provides  an  excdlent  mechanism  to  create  abstract  data 
types  that  map  to  the  real  world.  The  objects  and  operations  identified  for  the 
pauncel  post  abstraction  in  the  example  in  Attachment  1  support  the  requirements 
of  the  application  clearly.  This  reduces  logic  mors  in  implementing  tte  package 
body,  and  more  important,  in  using  the  abstraction  in  the  main  pipgnun.  Ada 
packages  support  data  abstraction,  which  allows  the  creation  of  objects  that 
correspond  to  real-world  entities.  The  result  is  maintainable  systems  and  the 
generation  of  code  that  can  be  reused. 

•  iTtfbrmation  Hiding.  The  unnecessary  d^ail  of  how  the  package  is  used  is  hidden 
firom  the  plication.  This  hiding  prevents  tte  ajplication  fiom  accessing  internal 
data  structures.  The  package  spedficatimi  serves  as  a  clean  interfiice  to  the 
package  body  and  hides  all  data  structures  within  the  body.  This  hiding  prevents 
a  programmer  from  directly  accessing  the  data  structures,  which  can  cause  two 
serious  problems: 

•  Isolation  of  Data  Integrity.  The  first  serious  problem  is  that  the  int^rity  of 
the  data  could  be  violated.  For  example,  a  programmer  could  decide  that  an 
object  to  be  placed  on  the  Pint  In  Fir^  Out  (FIFO)  queue  has  high  priority. 
Attachment  2  provides  a  queue  example.  Instead  of  using  the  desired 
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ENQUEUE  procedure,  the  programmer  adjusts  the  front  and  back  pointers  in 
the  queue,  placing  the  new  item  at  the  front  of  the  queue.  When  done 
incorrectly,  this  could  destroy  the  integrity  of  the  database.  As  a  "hack,"  this 
violation  would  typically  not  be  documented  and  not  be  adequately  tested.  If 
a  legitimate  requirement  exists  to  place  objects  at  the  top  of  the  queue,  a 
special  procedure  should  be  designed  as  part  of  the  package  to  provide  this 
capability. 

-  Undocumented,  Untested  Intetface.  The  second  serious  problem  associated 
with  directly  accessing  the  data  strucuires  is  that  this  direct  access  provides  an 
undocumented  coupling  to  the  data  structures  that  would  not  be  updated  should 
the  package  body  be  updated.  An  update  to  the  data  structures  to  improve 
performance,  add  new  Ainctionality,  or  correct  an  error  could  result  in  having 
code  somewhere  else  in  the  application  that  no  longer  can  work  as  intended. 
At  best,  this  code  may  have  no  effect  on  the  data  structure.  At  worst,  this 
code  may  totally  destroy  the  information  maintained  in  the  data  structure  and 
invalidate  it  for  other  use.  This  scenario  is  exactly  what  happened  in  1992  to 
the  code  that  controlled  the  switching  circuits  for  the  telephone  lines  to  New 
York  City  and  most  of  New  England.  The  misplacement  of  queue  pointers 
caused  the  telephone  system  to  crash  for  many  hours.  This  would  not  have 
happened  had  the  application  been  coded  in  Ada  with  effective  use  of 
packages.  Fortunately,  in  Ada,  the  only  interface  to  the  package  body  is 
through  the  package  specification.  Consequently,  the  Ada  package  is  a  highly 
important  feature  for  high-quality,  reliable  code  that  results  in  reduced  costs 
during  initial  software  development  and  later  during  life-cycle  maintenance. 

•  Completeness.  The  package  body  can  be  easily  tested  to  verify  that  it  completely 
satisfies  the  requirements  identified  in  the  pack^e  specification.  Because  the  only 
purpose  of  the  package  body  is  to  implement  the  interface  defined  in  the  package 
specification,  the  package  body  can  be  easily  evaluated  to  ensure  it  completely 
supports  the  interface.  This  minimizes  the  otherwise  frequent  surprises  found 
during  integration  where  requirements  are  not  satisfied. 

•  Confirmability.  The  package  body  can  be  easily  tested  to  confirm  that  it  correctly 
implements  the  pack^e  specification.  Because  the  only  inter&ce  to  the  code  in 
the  package  body  is  through  the  package  specification,  the  testing  problem  is 
simplified  and  results  in  correct  code  that  can  be  easily  integrated  into  othm* 
compilable  program  units. 

•  Modularity.  The  package  structure  provides  an  excellent  mechanism  for 
implementing  interfitces  and  supporting  the  migration  to  Open  Systems 
Environments  (OSEs)/Open  Systems  Architecture  (OS A).  Ada  is  recognized  by 
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the  National  Institute  of  Standards  and  Technology  (NIST)  as  having  a  strong 
stratt^ic  value  in  migrating  towards  OSE  (U.S.  Department  of  Commerce,  1991). 

hJl  STRONG  TYPING 

Perhaps  the  second  most  important  capability  in  the  Ada  language  is  the  feature  of  strong 
typing  coupled  with  the  associated  Ada  exception.  Together,  they  provide  a  c^nbility 
to  build  high-quality  software  by  automatically  identifying  many  programmer  errors 
during  software  development  at  compile  and  execution  times.  For  applications  with 
reliability,  &ult-tolerance,  and  safety-critical  requirements,  this  capability  provides  a 
iiwrhani«m  to  rctum  to  some  known,  safe  state  when  a  system  error  occurs.  This  section 
utTQwg  typing;  the  next  section  addresses  Ada  exceptions. 

LJl.l  l>pes  as  Building  Blocks 

An  Ada  type  characterizes  a  set  of  values  and  a  set  of  operations  applicable  to  those 
values.  Ada  provides  a  variety  of  types  that  can  be  used  as  building  blocks  to  create 
real-world  abstractions.  For  example.  Command  and  Control  (C2)  ^>plications  usually 
process  tracks  that  represent  an  aircraft,  ship,  or  submarine.  Important  information  is 
maintaifigri  on  each  track,  including  identification,  geogrsq>hical  latitude  and  longitude, 
altitude,  and  time  of  last  position  report.  The  following  type  definitions  may  be  used  to 
create  a  simple  abstract  track  type: 

type  identification  is  (fiiend,  foe,  unknown); 
type  latitude  is  digits  12  range  -W.O  ..  -^90.0;  —in  degrees 

type  longitude  is  digits  12  range  -180.0  ..  +180.0;  —in  degrees 
type  altitude  is  range  -1000  ..  +50CX)0;  —in  feet 

Associated  with  each  type  is  a  set  of  type-specific  operations  (e.g.,  addition  and 
multiplication  for  integers  and  reals).  These  types  can  be  used  as  building  blocks  for 
compound  user-defined  types  such  as  arrays  and  records.  The  record  is  used  to  define 
the  following  simple  logical  track  type: 

type  track_type  is 


record 

ID: 

identification; 

—track  ID 

lat: 

latitude; 

—track  latitude 

long: 

longitude; 

—track  longitude 

alt: 

altitude; 

—track  altitude 
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time:  calendar.time;  —time  track  position 

—last  updated 

—time  imported  from  package  calendar 
where  it  is  defined 

end  record; 

Creation  of  Objects  From  Types 

A  type  is  only  a  template  from  which  objects  can  be  created  with  a  known  set  of  values 
and  a  known  set  of  operations.  Objects  can  now  be  created  hrom  the  above  type 
definitions: 


X1,X2:  latitude; 

Y1,Y2:  longitude; 

A,B:  ttack_type; 

These  objects  can  now  be  assigned  values  such  as: 

XI:**  57.0;  —XI  becomes  57.0  degrees  North 

X2:  *  XI  -  60.0;  — X2  becomes  3.0  degrees  South 

Yl:«  -145.0;  — Y1  becomes  145.0  d^rees  West 

A:=  (friend,  XI,  Yl,  32_000,  calendar.clock); 

—ID  becomes  "ftiend" 

— lat  becomes  the  value  of  XI 
—long  becomes  the  value  of  Yl 
—alt  becomes  32,(XX)  feet 

— time  becomes  current  time  (result  of  function  clock  in  package 
calendar) 

An  alternative  method  of  expressing  this  last  assignment  statement  clearly  associates  the 
component  objects  of  A: 


A:* 


(ID  =  >  friend,  —ID  becomes  "friend" 


lat  =>  XI, 

long  =*>  Yl, 

alt  *>32_000, 

time  =*>  calendar.clock); 


—lat  becomes  the  value  of  XI 
—long  becomes  the  value  of  Yl 
—alt  becomes  32,0(X)  feet 
—time  becomes  current  time 


This  method  improves  the  understandability  of  the  code  for  both  programmers  and 
noiqvogrammers. 
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L.2.3  Handling  of  Objects  in  Homogeneous  and  Heterogeneous  Environments 
Once  objects  have  been  deHned,  the  use  of  these  objects  as  a  single  entity  facilitates  use 
within  the  application,  for  example: 

B  :  =  A;  -  The  objects  in  record  B  (of  track^type)  are  set  to  those  of  record  A.  This  is 


equivalent  to: 

B.ID  :« 

A.ID; 

B.lat  :» 

A.lat; 

B.long  :  = 

A.long; 

B.alt  :* 

A.alt; 

B.time  :  = 

A.time; 

This  convenient  notation  provides  the  most  efficient  means  for  handling  the  object  within 
homogeneous  computing  environments  for  assignments,  bus  transfers,  Input/Ou^ut  (I/O), 
and  other  operations.  A  pack/unpack  facility  provides  support  for  interfacing  the  object 
to  heterogeneous  computing  environments.  In  this  way,  the  object  can  be  handled 
efficiently  with  one’s  own  computer.  When  the  object  is  ready  to  be  communicated  to 
a  different  computer  system,  it  can  be  "paclod"  into  the  agreed-upon  interface  or 
message  format. 

L^.4  Elimination  of  Illegal  Expressions  and  Assignment  Statements 
Strong  typing  eliminates  errors  by  preventing  illegal  expressions  and  illegal  assignments 
of  different  types  at  compile  time.  For  example,  what  is  the  result  of  adding  five  apples 
to  six  oranges?  In  normal  mathematical  situations,  this  is  undefined.  Hence,  the 
following  is  undefined  in  reality  and,  in  Ada,  would  be  declared  illegal  at  compile  time: 

X  H-  Y 1  —illegal  expression 

—adding  a  latitude  to  a  longitude  is  undefined 

Y2:sXl;  —illegal  assignment  statement 

—assigning  a  latitude  to  a  longitude  is  also  undefined 

The  prevention  of  illegal  expressions  and  illegal  assignments  at  compile  time  reduces 
many  common  logic  errors  found  in  most  other  languages.  Although  adding  latitude  to 
longitude  is  normally  undefined  and  undesired,  the  user  may  choose  to  define  such  an 
operation  in  Ada. 

L^.5  ESimination  of  Constraint  Errors  at  Compile  Time 

In  addition,  strong  typing  eliminates  errors  by  providing  constraint  checking  to  ensure 
that  all  range  values  associated  with  the  type  definition  are  satisfied.  For  example, 
objects  of  type  latitude  are  assigned  to  range  from  -90  degrees  South  to  +90  degrees 
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North.  In  nomnal  mathematical  situations,  a  value  outside  of  this  range  would  have  no 
meaning.  Hence,  the  following  statements  would  be  illegal: 

XI  :  =  127.0;  —illegal  as  127  degrees  exceeds  the  range  constraint  of  90 
degrees  North 

L^.6  Elimination  of  Constraint  Drors  at  Run  Time 

Constraint  errors  may  be  identified  at  compile  time  and  also  at  run  time  (during  program 
execution).  The  following  statement  is  legal  for  values  of  XI  less  than  and  equal  to  7S 
degrees;  it  is  illegal  when  XI  is  greater  than  75  degrees: 

X2  :=  XI  +  15.0;  —possibly  illegal— only  known  at  run  time 

Constraint  checking  during  run  time  is  important  during  software  development  and  testing 
because  it  allows  errors  to  be  easily  detected  and  code  corrected  or  handled,  as 
sqipropriate.  Constraint  checking  is  also  important  during  execution  in  the  mission 
environment.  Should  errors  be  detected,  an  exception  can  be  raised  that  allows  the 
software  to  take  the  appropriate  action. 

L  J  EXCEPTIONS 

Ada  exceptions  were  included  in  the  language  to  support  reliability,  fault  tolerance,  and 
safety  critical  requirements.  During  the  execution  of  a  program,  sdl  sorts  of  errors  can 
occur  that  could  result  in  grave  consequences.  A  zero  divide  could  cause  a  computer  to 
crash  during  critical  terrain>following  maneuvers;  an  out-of-bound  index  to  a  database 
could  cause  the  entire  database  to  be  corrupted;  an  out-of-bound  index  to  an  array  could 
cause  a  weapon  to  be  launched  against  friradly  forces;  and  an  exceeded  c^jacity  limit 
could  cause  a  weapon  to  miss  the  target.  Errors  can  result  from  hardware  faults, 
network  faults,  capacity  limits,  or  software  logic.  Some  errors  are  easy  to  predict;  others 
are  next  to  impossible.  Regardless  of  the  cause  of  the  error,  the  excq>tion  feature  in  Ada 
provides  an  excellent  mechanism  to  programmatically  recover  and  return  to  some  known, 
safe  state  and  continue  processing.  This  is  important  for  many  applications  where  the 
mission  would  be  at  risk  if  the  computer  had  to  be  shut  down  and  rebooted. 

Without  exceptions,  programmers  would  have  to  test  for  each  possible  error  condition 
and  would  occasionally  miss  a  possible  error.  In  Ada,  a  set  of  predefined  exceptions 
exists  that  can  automatically  identify  typical  processing  errors.  It  is  also  possible  for  the 
user  to  define  additional  error  conditions  that  can  be  detected.  When  an  error  condition 
is  detected,  an  exception  is  raised.  Should  an  exception  handler  be  defined  for  the 
excqition,  an  aj^ropriate  action  could  be  taken  to  return  the  program  to  a  known  safe 
state.  If  an  nception  handler  is  not  defined,  the  program  will  crash  just  as  a  FORTRAN 
or  C  program  does. 
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Examples  of  predeEned  exceptions  are  shown  with  the  parcel  abstiactitm  example  in 
Attadiment  1,  the  queue  example  in  Attachment  2,  and  the  queue  generic  example  in 
Attachment  3. 

L.4  GENERICS 

Generics  are  the  building  blocks  of  reusable  software  systems.  Reuse  is  not  only 
important  for  economies  across  applications  but  also  can  be  very  important  within  a 
single  application. 

The  example  of  the  queue,  presented  in  Attachment  2,  can  be  a  necessary  artifact  to 
many  portions  of  a  single  application.  The  queue,  as  presented  in  the  attachment,  is  not 
very  ^q^plicable  for  general  use.  It  is  only  useful  for  objects  of  type  PARCELJTYPE 
going  to  a  queue  containing  a  maximum  of  100  objects.  In  the  past,  such  a  queue  could 
only  be  reused  by  hard  coding  the  desired  type  and  size.  Making  the  necessary  dianges 
by  hard  coding  such  code  is  extremely  error  prone  when  code  is  complex  or  nontrivial. 
Ada  provides  an  elegant  solution.  This  queue  can  be  made  useful  to  other  requirements 
in  the  same  application  by  converting  it  into  a  graeric.  A  generic  provides  a  template 
from  which  new  Ada  code  can  be  built.  Conversion  to  a  generic  requires  minor  changes 
to  the  package  specification  and  package  body,  some  generic  parameters,  and  a  generic 
instantiation.  A  generic  instantiation  is  a  formal  Ada  construct  that  creates  a  logical 
instance  of  the  generic  code  by  filling  in  the  template  with  the  generic  parameters. 

The  queue  example  in  Attachment  2  has  been  converted  to  a  generic  queue  example  in 
Attachment  3.  This  example  establishes  generic  parameters  for  (1)  the  type  of  item  to 
be  managed  by  the  queue  and  (2)  the  size  of  the  queue.  The  example  shows  the  genoic 
instantiation  necessary  to  create  an  instance  equi^ent  to  the  queue  of  Attachment  2.  It 
also  exemplifies  the  way  this  generic  queue  can  be  used  to  create  a  queue  for  any  type 
of  any  size  (up  to  system  limits). 

The  power  of  this  generic  queue  is  considerable,  (^eues  can  now  be  built  for  any 
desired  type  for  any  desired  size  and  used  over  and  over  again  even  within  the  same 
application.  This  generic  can  be  instantiated  to  process  pareds  for  shipping,  radar 
messages.  E-mail  messages,  financial  data,  stock  quotes,  or  any  data  type  desir^  and 
for  any  quantity  up  to  hardware  limits. 

Once  the  generic  is  built  and  thoroughly  tested,  the  cost  of  reusing  the  code  is 
significantly  reduced.  Most  errors  will  be  detected  and  corrected  when  the  code  is  first 
developed.  This  means  that  the  cost  and  risk  to  a  subsequent  user  will  be  less  than  that 
of  devdoping  the  code  from  scratch. 
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Fuithomore,  reuse  of  code  results  in  higher-quality  applications.  As  the  code  is  reused 
and  corrected  for  each  instantiation,  fewer  defects  be  found  by  subsequent  users. 
Conections  made  by  subsequent  users  can  be  reapplied  to  an  earlier  application  during 
the  next  upgrade. 

Ada  LIBRARY  (SEPARATE  COMPILATION) 

Ada  provides  a  library  mechanism  that  supports  integration  and  programming-in-the-laige 
requirements.  Library  units,  such  as  package  ^)ecifications,  package  bodies,  and  main 
programs,  are  managed  separately.  Consequently,  each  library  unit  can  be  compiled 
sqnrately  when  the  package  specifications  are  known.  This  is  important  for  developing 
lai^e  systems.  Such  an  application  can  be  divided  among  many  developers  by  defi^g 
s^ropriate  interfaces  using  the  Ada  package.  Dummy  code  or  stubs  can  te  used  to 
simulate  the  interface  for  testing  and  prototyping  purposes.  Later  during  integration,  the 
completed,  developed  code  can  be  very  easily  integrated  because  all  portions  of  the  code 
were  developed  by  using  the  same  interfaces. 

The  package  body  can  be  separately  compiled  from  the  package  specification.  This  also 
supports  integration  by  reducing  the  time  necessary  to  r^uild  a  complete  system.  In  the 
past,  should  an  error  te  found  in  the  system,  the  entire  system  had  to  be  recompiled  and 
linked.  This  frequently  took  days.  Most  execution  errors  are  typically  found  in  the 
detailed  implementation  in  the  package  body.  In  Ada,  when  such  errors  are  corrected, 
only  die  package  body  needs  to  be  recompiled  and  the  system  relinked.  Because  this 
should  be  a  very  small  part  of  the  system,  a  complete,  recompiled  system  can  be 
generated  rather  quickly. 

In  addition,  procedures  and  functions  can  be  (ximpiled  either  as  part  of  a  library  unit  or 
separately.  This  provides  a  considerable  amount  of  flexibility  when  developing  the 
design  of  an  application  and  supporting  early  prototypes. 

L.6  Ada  TASKING 

Ada  tasldng  provides  a  capability  to  support  logical  parallel  processing  within  an  Ada 
sqiplication.  The  Ada  tasking  model  provides  an  excellent  and  portable  capability  to 
maintain  sqiarate  threads  of  control,  synchronize  asynchronous  activities  when  necessary, 
and  communicate  among  these  separate  threads  of  control.  Tasking  is  a  rather  advanced 
language  feature  not  found  in  other  languages.  When  tasking  is  used,  a  special  Run¬ 
Time  Environment  (RTE)  is  evoked  to  schedule  tasks,  process  interrupts,  and  provide 
other  services.  It  can  be  highly  valuable  to  a  wide  variety  of  applications  including  real¬ 
time  applications,  simulation,  prototyping,  and  networking.  To  use  tasking  effectively, 
one  must  understand  the  Ada  tasking  model  and  have  a  design  methodology  that  supports 
the  model.  It  is  recommended  that  compilers  be  carefully  evaluated  because  some  Ada 
compiler  implementations  provide  far  superior  suf^rt  for  tasking  than  others. 
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The  Ada  tasking  model  may  be  inappropriate  for  some  applications  because  the  overhead 
to  support  logical  parallel  processing  may  not  justify  the  benefits  obtained.  Many 
organizations  find  ttot  interrupt-driven  sequential  processing  satisfies  all  requirements, 
and  tasking  is  unnecessary.  When  the  application  is  hosted  on  an  operating  system  or 
executive,  it  may  be  practical  not  to  use  ta^ng  in  fovor  of  the  run-time  provided  by  the 
environment.  Common  sense  should  prevail  as  to  whether  the  Ada  tasking  model  is 
^)pro(»iate  for  a  given  application. 

The  Ada  tasking  model  for  Ada  9X  will  be  enhanced  to  directly  support  parallel 
processing  with  parallel  processors  and  highly  distributed  environments.  Section  7.1 
provides  additional  information  on  Ada  9X. 

L.7  FEATURES  THAT  FACILITATE  SOFTWARE  ENGINEERING 
The  above-described  features  of  packages,  strong  typing,  exceptions,  generics,  separate 
compilation,  and  tasking  are  important  facilitators  to  software  engineering.  In  addition, 
there  are  many  other  features  in  the  Ada  language,  too  numerous  to  detail  here,  including 
subtypes,  access  types,  attributes,  representation  clauses,  I/O,  visibility,  and  program 
libraries.  Although  the  Ada  language  is  a  cornerstone  of  software  engineering, 
supporting  quality,  cost,  and  schedule  benefits,  Ada  is  only  a  facilitator.  One  must  be 
educated  and  trained  to  use  Ada  with  software  engineering.  Section  8  of  Volume  I 
provides  guidance  for  obtaining  the  necessary  education  and  training  within  an 
organization.  Without  the  knowledge  and  skills  to  use  these  Ada-provided  software 
engineering  features,  a  programmer  is  likely  to  write  programs  in  the  same  style  of  other 
languages,  resulting  in  code  with  the  same  inefficiencies  of  other  languages. 
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Attachment  1 

Example— Package  Specification:  Parcel 
Abstraction  Example 

A  simple  example  of  an  Ada  padcage  can  be  demcmstrated  with  an  automated  post  office 
example.  Suppose  the  post  office  built  a  system  to  automatically  process  parcels  for 
shipping.  The  design  for  such  a  system  may  be  d)ject  oriented  with  abstractions  for  the 
parcel,  the  customer,  money  collection,  and  parcel  routing.  A  package  could  be  created 
for  eadi  of  these  abstractions  with  a  main  program  to  control  the  overall  processing 
requirements.  Each  package  would  have  a  package  q)ecification  and  a  package  body. 

Hie  following  shows  an  example  of  an  Ada  package  specification.  It  is  an  abstraction 
of  a  parcel  for  shipping  in  the  post  office  system.  This  abstraction  provides  a  phyacal 
description  of  the  length,  width,  height,  and  wdght  of  the  parcel.  It  includes  shipping 
data  on  origination  post  office,  destination  post  office,  and  method  of  shipment.  It 
includes  operations  on  the  parcel  such  as  get  physical  data,  get  shipping  data,  and 
compute  shipping  cost. 

The  main  program  may  use  the  operations  provided  through  the  following  code: 

GET.PARCEL  PHYSICAL  DATA  (physical  data); 

GET.PARCEL  SHIPPING  DATA  (shippingjdata); 

COMPUTE.PARCEL^SHIPPING.COST  (physical.data,  shipping_data, 
shipping^cost): 

The  Ada  package  specification  is  an  interface  between  the  main  program  and  the  code 
that  does  the  real  work.  The  body  of  the  PARCEL_POST  package  would  contain  the 
necessary  code  to  implement  the  operations  of  GCT  PARCEL  PHYSICAL  DATA, 
GET_PARCEL_SHIPPING_DATA,andCOMPUTE  PARCEL  SHIPPING  COST.  The 
exceptions  INVALID_ZIP_CODE,  PARCEL_EXCEEDS_^GHT_LIMITS,  and 
PARCEL_EXCEEDS_S1ZE_LIM]TS  may  be  raised  when  error  conditions  are  detected. 
The  ex^tion  INVALID_23P_CODE  excepticm  would  be  raised  when  an  invalid 
destinadcm  (or  origin)  sip  code  is  detected  for  the  pared.  The  excqition 
PARC£L_EXCEEDS_WEIGHT_LIMITS  would  be  rdsed  when  the  pared  exceeds  the 
maximum  limit  of  50  pounds.  The  PARCEL_EXCEEDS_SIZ£_L1MITS  would  be  raised 
when  the  pared  excels  the  post  office  size  limits.  In  each  case,  supplication  interfacing 
widi  the  pared  abstraction  would  handle  the  excqitions.  In  the  case  of  the  excessive 
weight  and  size  limits,  the  application  may  tell  the  customer  that  the  parcel  is  rejected 
and  return  it  to  the  customa*.  In  the  case  of  an  invalid  zip  code,  the  sqpplication  may 
request  another  zip  code  from  the  customer.  The  package  specification  for  the  pared 
abstraction  is  as  follows: 
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padkvfe  PARCEL_ABSTRACnON  is 
Qfpe  INCHES  is  new  fleet; 

Qrpe  POUNDS  is  new  float; 
type  PARCEL_PHYSICAL_DESCRIPnON  is 
fecotd 

LENGTH:  INCHES;  — length  of  pared  in  mches 

WIDTH:  INCHES;  —width  of  pared  in  mAas 

HEIGHT:  INCHES;  height  of  pared  in  hKhes 

WEIGHT:  POUNDS;  — wd^  of  pared  in  r«— *«»« 

end  record; 

Qfpe  MODE_OF_SHIPMENT  is  (SURFACE,  AIR);  —dipping  options 
type  ZIP  CODE  it  new  int^er  range  0  ..  99999;  —standard  poatd  zip  code 
type  PARCEL_SHIPPING_DESCRIFT10N  is 
record 


FROM:  ZIP_CODE;  — originatioo  poet  office 

TO:  ZIP  CODE;  —destination  poet  office 

SHIPMENT:  MODE.OF.SHIPMENT; 

end  record; 

type  DOLLAR  is  new  float;  —cost  of  shipping  pared  post  in  ddlars 

type  PARCELJTYPE  is 
record 

physicd.data:  PARCEL  PHYSICAL  DESCRIPTION; 

ahippin£.data:  PARCEL~SHIPPINGjbESCRIPnON; 

*^PP>>>g.oost:  DOLLAlf:-  0.0; 

end  record; 


procedure  CET_PARCEL_PHYSICAL  DATA  ( 

pbysicd.data:  out  PARCEL.PHYSICAL^DESCRIPTION); 

procedure  GET_PARCEL_SHIPPING^DATA  ( 

PARCEL_SHIPPING_DESCRIFTION); 

procedure  COMPUTE.PARCEL.SHIPPING  COST( 

physkd.data:  in  PARGEL  PHYSICAL  DESCRIPTION; 
shipping_data:  in  PARCEL'sHIPPING .DESCRIPTION; 
^PPii>S_cod:  out  DOLLAIU; 


excqitioo:  INVALID  ZIP  CODE; 

exception:  PARCEL.^CEEDS  WEIGHT  LIMITS; 

exception:  PARCEL.EXCEEDSlsiZE.UMITS; 

end  PARCEL.ABSTRACnON; 
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Package  Specification  and  Package  Body:  Queue 
Example 

A  simple  example  of  a  complete  package  can  be  demonstrated  with  the  imfdementation 
of  a  queue.  A  qumie  is  a  fr^uendy  used  software  mechanism  to  buffer  (or  synchronize) 
data  from  one  process  to  another.  It  is  also  known  as  a  FIFO  buffer.  It  is  similar  in 
concq>t  to  a  queue  of  customers  waiting  to  be  serviced  at  a  bank.  Basically,  die  queue 
has  two  operations:  enqueue  and  dequeue.  When  a  new  customer  arrives,  the  customer 
enters  the  queue  or  is  "oiqueued.”  When  the  customer  finally  reaches  the  bank  tdler, 
the  bank  teller  tair^  the  customer  off  of  the  queue  or  "dequeues”  the  oistomer  for 
processing. 

A  package  specification  for  a  queue  for  data  of  type  PARCEL  (defined  in  Attachment  1, 
die  parcel  abstraction  example)  capable  of  holding  100  objects  is  described  in  die 
following  example.  Such  a  queue  may  be  used  in  a  distributed  automated  i^lication  to 
process  parcels  for  routing  to  their  destination  post  office.  Please  note  that  the  package 
PARCEL_ABSTRACnON  is  imported  for  use  by  the  QUEUE  package  through  the 
"with"  and  "use"  clause  on  the  fim  line. 

There  are  two  exceptions.  The  UNDERFLOW  excqition  is  raised  when  there  is  an 
attempt  to  dequeue  an  object  and  the  queue  is  empty.  The  response  here  for  an  micqition 
handler  could  be  to  process  something  else  and  come  back  to  process  objects  in  diis 
queue  later.  The  OVERFLOW  exception  is  raised  when  the  capacity  limits  are 
exceeded,  in  this  case  100  objects  in  the  queue.  When  there  is  an  attempt  to  enqumie  the 
101st  object  into  the  queue,  there  is  no  space  for  the  new  object.  In  other  languages, 
data  are  usually  lost.  In  Ada,  the  excqition  handler  could  preserve  the  data  and  cause 
die  process  dequeuing  objects  off  the  queue  to  have  a  higho’  priority. 

with  PARCEL_ABSTRACTION;  use  PARCEL_ABSTRACTION; 

package  QUEUE  is 

procedure  ENQUEUE  (parcel j^ject:  in  PARCELJTYPE); 

—enqueues  parcel.object  of  type  PARCELJTYPE  cmto  queue 
procedure  DEQUEUE  (parceljibject:  out  PARCELJTYPE); 

—dequeues  parcel.object  of  type  PARCEL_TYPE  from  queue 
UNDERFLOW:  exceptitm; 

— excqition  rai^  when  queue  is  empty 
OVERFLOW:  exception; 

— excqition  raised  when  capacity  limits  are  reached 
end  QUEUE; 
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The  body  to  suj^rt  such  a  package  q)ecificatioii  may  look  like: 

package  body  QUEUE  is 

queue:  array  (0  ..  99)  of  PARCELJTYPE; 

—note  name  queue  is  overloaded 
front:  natural  :■  0;  —front  of  tf»e  queue 

back:  natural  :"0;  —back  of  the  queue 

procedure  DEQUEUE  (parceljobject:  out  PARCELJTYPE  is 
b^in 

if  front  »  back  then 

raise  UNDERFLOW; 
else 

parcel_object:«  queue(front); 
front: «  (front+1)  mod  100; 
end  if; 

end  DEQUEUE; 

procedure  ENQUEUE  (parceljobject:  in  PARCELJTYPE  is 
b^n 

if  (back+1)  mod  100  »  front  then 
raise  OVERFLOW; 
else 

back:s  (back+1)  mod  1(X); 
qumie(back):»  pmcel.object; 
end  if; 

end  ENQUEUE; 
end  QUEUE; 

Procedures  DEQUEUE  and  ENQUEUE  would  be  used  by  the  application  using  the 
package  with  param^ers  for  an  object  A  of  type  PARCELJTYPE  as: 

ENQUEUE  (A);  —enqueues  object  A 

DEQUEUE  (A);  —dequeues  object  A 
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Attachment  3 

Generic  Package:  Generic  Queue  Example 

This  etample  deimmstrates  the  use  of  Ada  generics.  For  ease  of  comparison,  this 
example  provides  a  generic  cs^nbility  to  the  queiw  provided  in  Attadiment  2.  To  convert 
die  queue  presented  in  Attachment  2  to  a  generic,  die  size  of  the  queue  and  a  place- 
holdv  for  the  type  are  established  as  generic  parameters  immediately  before  the  padoge 
spedfication: 

generic 

SIZE  :  positive;  —any  positive  to  be  instantiated 

type  ANYJTYPE  is  private;  — ANYJTYPE  to  be  instantiated 

package  QUEUE  is 

procedure  DEQUEUE  (any_object:  out  ANYJTYPE); 
procedure  ENQUEUE  (any_object:  in  ANYJTYPE); 

UNDERFLOW:  exception; 

OVERFLOW:  exception; 
end  QUEUE 

Both  the  SIZE  and  ANYJTYPE  would  be  provided  later  as  parameters.  The  package 
qiecification  has  been  modified  to  reflect  the  new  type  ANY_TYPE: 

The  package  body  is  modified  to  reflect  both  the  new  type  ANY  TYPE  and  the  queue 
SIZE; 


package  body  QUEUE  is 

type  table  is  array  (positive  range  <>)  of  ANY_TYPE; 
qumie:  table(0.. (SIZE-1)); 
front:  natural 0; 
back:  natural  :=0; 

procedure  DEQUEUE  (any_object:  out  ANYJTYPE)  is 
tx^in 

if  front  «  back  then 

raise  UNDERFLOW; 
else 

any_object:=  queue(front); 
flront:-  (front+1)  mod  SI^; 
end  if; 

end  DEQUEUE  ; 
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procure  ENQUEUE  (any.object:  in  ANY_TYPE)  is 
b^in 

if  (back+1)  mod  SIZE  «  front  then 
raise  OVERFLOW: 
else 

back:*  (back+1)  mod  SIZE; 
qumie(back):*  any_object; 
end  if; 

end  ENQUEUE; 
end  QUEUE; 

To  instantiate  the  queue  for  a  size  of  100  objects  of  type  PARCELJTYPE,  the  following 
generic  instantiation  is  made: 

package  PARCEL.QUEUE  is  new  QUEUE  (100,  PARCEL.TYPE); 

To  instantiate  the  queue  for  a  size  of  1,(XX)  objects  of  type  TRACKJTYPE,  die  following 
generic  instantiation  is  made: 

package  TRACK_QUEUE  is  new  QUEUE  (1000,  TRACKJTYPE); 

Procedures  DEQUEUE  and  ENQUEUE  are  used  as  above,  the  calling  application  not 
even  knowing  that  these  procedures  are  from  an  instantiated  package.  With  A  being  an 
object  of  type  PARCEL^TYPE  and  B  being  an  object  of  type  TRACK_TYPE,  then  the 
ftdlowing  operations  can  be  made: 

ENQUEUE 
ENQUEUE 
DEQUEUE 
DEQUEUE 


(A);  —enqueues  object  A  into  the  PARCEL^QUEUE 

^);  —enqueues  object  B  into  the  TRACK_QUEl^ 

(A) ;  —dequeues  object  A  from  the  P^CEL^QUEUE 

(B) ;  —dequeues  object  B  from  the  TRACK_QUEUE 
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Supplementary  Reading 

This  qipendix  lists  publications,  including  Software  Engineering  Institute  (SEI) 
reports  on  data  ri^ts,  that  are  useful  to  Program  Managers.  Reports  that  have 
Defense  Tedinical  Information  Gmter  (DTIC)  numbers  are  available  from  DTIC 
and  the  National  Technical  Information  Service  (NTIS)  at  the  followii^  addresses: 

DTIC  Defense  Technical  Information  Center 
Attn.:  FDRA  Cameron  Station 
Alexandria,  VA  22304-6145 

Nils  National  Technical  Information  Service 
U.S.  Department  of  Commerce 
Springfield,  VA  22161 

SEI  reports  that  have  a  DTIC  number  (i.e.,  ADA  followed  by  six  digits)  may  be 
obtained  directly  from: 

Software  Engineering  Institute  * 

Atm.:  Publications  Requests 
Camegie-Mellon  University 
Pittsburgh,  PA  15213-3890 

SEI  affiliates  and  Governmental  organizations  may  order  documents  directly  from 
SEI  by  submitting  a  written  request,  accompanied  by  a  mailing  label  with  the 
requestor’s  address,  to  the  above  address. 


Data  Rights  Reports 

Martin,  A.  and  K.  Deaty.  Seddng  the  Balance  Between  Government  and  Industry 
Interests  in  Software  AcquisitiorL  Volume  I:  A  Basis  ftn  Reconciling  DOD  and  Industry 
N^ds  for  Rights  in  Software  (CMU/SEI-87-TR-13,  ADA185742).  Pittsburgh,  PA: 
Camegie-Mellon  University,  1987. 

Martin,  A.  and  K.  Deaty.  The  Effect  of  Software  Support  Needs  on  DOD  Software 
Acquisition  Policy:  Part  1:  A  Framework  far  Anafyzing  Legal  Issues  (CMU/SEI-87- 
TR'2,  ADA178971).  Pittsburgh,  PA:  Camegie-Mellon  University,  1987. 
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Samuelson,  P.  Understand^  the  Implicatums  of  Setting  Ri^us  in  Software  to  the 
D^ense  Department:  A  Journ^  Throu^  the  Regulatmy  Maze  (SEI-86-TM-3, 
ADA17S166).  Pittsburgh,  PA:  Camegie-Melloii  University,  1986. 

Sanmelson,  P.  Comments  on  the  Proposed  Defense  and  Federal  Acquidtitm  R^ulatkms 
(SEI>86-TM-2,  ADA17S16S).  Pittsburgh,  PA:  C^unegie-Mellon  University,  1986. 

Samuelson,  P.  Adequate  Planning  for  Acquiring  Suffidera  Documentation  About  and 
Rights  in  Software  to  Permit  Organic  or  Competitive  Mainterumce  (SEI-86-TM-1, 
ADA17S167).  Pittsburgh,  PA:  Camegie-Melion  University,  1986. 

Samuelson,  P.  and  K.  Dea^.  Intettectual  Property  Protection  for  Software  (SEI-CM-14- 
2.1).  Pittsburgh,  PA:  Camegie-Melion  University,  1989. 

Samuelson,  P.,  et  al.  Proposal  for  a  New  "Ri^Os  in  Software"  Clause  for  Software 
Acquisitioru  by  the  Department  of  D^ense  (CMU/SEI-86-TR-2,  ADA182093). 
Pittsburgh,  PA:  Camegie-Melion  University,  1986. 
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Appendix  N 

Comparison  of  Ada  to  Assembly:  F-15  Structural 
Filter  Example 

Coding  in  High  Order  Languages  (HOLs),  such  as  Ada,  has  important  benefits  when 
conq)ared  to  coding  in  Assembly.  These  benefits  were  demonstrated  for  the 
conq>utation  of  the  Structural  Filter  as  part  of  the  F-15  integrated  flight  control 
system,  which  was  flown  in  September  1984.  The  formula  for  the  S-Plane 
Representation  of  the  Structural  Filter  was: 

0.4807S^  +  83.5533S  +  3894 


S^  +  125S  +  3894 

This  formula  converts  to  the  difference  equation  representation  of: 

STFL-  0.56503  •  PRESTRU  -  033991  •  PREMISTRU  +  0.089533  • 
PREM2STRU  +  0.87711  •  STFMl  -  0.19182  •  STFLM2 

The  Ada  representation  of  the  difference  equation  is  nearly  equivalent: 

STFL:=  036503  •  PRESTRU  -  033991  •  PREMISTRU  +  0.089533  • 
PREM2STRU  +  0.87711  •  STFMl  -  0.19182  *  STFLM2; 

The  only  necessary  changes  are  the  for  the  assignment  and  the  semicolon  to 
terminate  the  statement  Contrast  this  with  the  Assembly  version  that  was  in  the 
previous  version  of  the  F-15: 


LDL 

RR10,PCAS24; 

%  RR8  Contains  PRESTRU 

CALL 

FMUL; 

%  036503  •  PRESTRU 

LDL 

RR6.  RR8; 

%  Store  Result  for  Later  Use 

LDL 

RR8,  PREMISTRU; 

LDL 

RRIO,  PCAS25; 

CALL 

FMUI; 

%  03391  •  PREMISTRU 

LDL 

RR10,RR8; 

%  Prepare  for  Subtraction 

LDL 

RR8,RR6; 

CALL 

FSUB; 

%  RR6-[033991  •  PREMISTRU] 

LDL 

RR6,RR8; 

%  Store  Result  for  Later  Use 

LDL 

RR8,PREM2STRU; 

LDL 

RR10,PCAS26; 
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CALL 

FMUL; 

%  0.089533  •  PREM2STRU 

UDL 

RR10.RR6; 

CALL 

FADD; 

%  RR6  +  [0.089533  •  PREM2STRU] 

LDL 

RR6.  RR8; 

%  Store  Result  for  Later  Use 

LDL 

RR8,STFLM1; 

LDL 

RR10J*CAS27; 

CALL 

FMUl; 

%  0.87711  •  STFLMl 

LDL 

RR10,RR6; 

CALL 

FADD; 

%  RR6  +  [0.87711  •  STFLMl] 

LDL 

RR6JU18; 

%  Store  Result  for  Later  Use 

LDL 

RR8,STFLM2; 

LDL 

R10J»CAS28; 

CALL 

FMUl; 

%  0.19182  •  STFLM2 

LDL 

RR10.RR8; 

%  Prepare  For  Subtraction 

LDL 

RR8,RR6i 

CALL 

FSUB; 

%  RR6  -  [0.19182  •  STFLM2] 

LDL 

STFI,RR8 

CALL 

FMUL; 

%  0.089533  •  PREM2STRU 

This  Assembly  example  uses  a  floating-point  algorithm;  had  a  fixed-point  one  been 
used,  it  would  have  been  twice  as  long. 
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LIST  OF  ACRONYMS  AND  ABBREVIATIONS 


AAS 

Advanced  Automation  System 

ABET 

Ada-Based  Envirromoit  for  Test 

ACEC 

Ada  Compiler  Evaluation  Csq)ability 

ACES 

Ada  Compiler  Evaluation  System 

ACM 

Association  for  Computing  Machinery 

ACSE 

Associaticm  Qmtrol  Service  Element 

ACUE 

Aircraft  Control  Unit  Emulator 

ACVC 

Ada  Compiler  Validation  Capability 

AdalC 

Ada  Information  Qearinghouse 

AdaICBB 

Ada  Information  Qearinghouse  Bulletin  Board 

AdaJUG 

Ada  Joint  (Services)  Users  Group 

AdaPSE 

Ada  Programming  Support  Environment 

ADP 

Automatic  Data  Processing 

AES 

Ada  Evaluation  System 

AFATDS 

Advanced  Field  Artillery  Tactical  Data  System 

AFB 

Air  Force  Base 

AFCEA 

Armed  Forces  Communications  and  Electronics  Association 

AFDSRS 

Air  Force  Defense  Software  Rqwsitory  System 

AFSC 

Air  Force  Systems  Command 

AFSPACECOM 

Air  Force  Space  Command 

AI 

Artificial  Intelligence 

AIE 

Ada  Int^rated  Environment 

AIS 

Automated  Information  System 

AIU 

Acoustic  Interface  Unit 

AJPO 

Ada  Joint  Program  Office.. . 

ALS 

Ada  Language  System 

ALS/N 

Ada  Language  System/Navy 

AMMWS 

Advanced  Millimeter  Wave  Seeker 

AMPS 

Advanced  Message  Processing  System 

ANSI 

American  Natioiud  Standards  Institute 

AP 

Acquisition  Plan 

AP 

Arithmetic  Processor 

APB 

Acquisition  Program  Baseline 

API 

Application  Programming  Interfoce 

APID 

Application  Programming  Instructional  DqKirtmait 

APP 

Application  Portability  Profile 

APT 

Advanced  Programming  Technique 

ARB 

Acquisition  Review  Board 

ARLB 

Ada  Reuse  Library  Browser 
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ARPA 

Advanced  Research  Projects  Agency 

ARTX 

Ada  Run-Time  Executive 

ASEET 

Ada  Software  Engineering  Education  and  Training 

ASI 

Application  Software  Interface 

ASIS 

Ada  Senumtic  Interface  Specificaticm 

ASP 

Acquisition  Strata  Plan 

ASR 

Ada  Software  Rq)ositoty 

ASSET 

Asset  Source  for  Software  Engineering  Technology 

AST 

Advanced  Systems  Tedmology 

ASW 

Anti-Submarine  Warfare 

ASWSOW 

Anti-Submarine  Warfare  Standoff  Weapon 

AT&T 

American  Telq>hone  &  Tdegnph 

ATCCS 

Army  Tactical  Command  and  Control  System 

ATT) 

Aircrew  Training  Device 

ATE 

Automated  Test  Equipment 

ATP 

Advanced  Tactical  Fighter 

ATJP 

Ada  Technology  Insertion  Program 

AXIS 

A  Tool  Intt^radon  Standard 

ATRIM 

Aviation  Training  and  Readiness  System 

AVF 

Ada  Validatitm  Facility 

BAFO 

Best  and  Final  Offer 

BBS 

Bulletin  Board  System 

BMS 

Broadcast  Message  Server 

BP 

Badqilane 

C2 

Command  and  Control 

C2I 

Command,  Control,  and  Intelligence 

C3I 

Command,  Control,  Communications,  and  Intelligence 

C4I 

Command,  Control,  Communicatitms,  Computers,  and 
InteUigenoe 

CAB 

CACM 

Common  Ada  Baseline 

CAD 

Computer-Aided  Des^ 

CAI 

Computer-Aided  Instruction 

CAIS 

Common  Ada  PSE  Interfoce  Set 

CALS 

Computer-aided  Acquisition  and  Logistics  Support 

CAM 

Computer-Aided  Mimufacture 

CAMP 

Common  Ada  Missile  Packages 

CARDS 

Central  Aidiive  for  Reusable  Defense  Software  Program 

CASE 

Computer-Aided  Software  Engineering 

CAS  REPS 

Casualty  RqKmting  System 

Acronyms  and  Abbraviations 


CAUWG 

CAXI 

CC&I 

ccnr 

cca» 

CCS 

CDA 

CDB 

CDIF 

CDPA 

CDR 

CDRL 

CECOM 

CERT 

CERT/CC 

CFE 

CGI 

CGM 

a 

CIF 

CIM 

CLNP 

CLOC 

CMM 

CMP 

CMS-2 

CMU 

CMU/SEI 

CNO 

COBOL 

COE 

COEA 

COMNAVCOMTELCOM 

COMSPAWARSYSCOM 

CONORS 

CORBA 

COTS 

CPDL 

CPP 

CPS 


Commerdal  Ada  Users  Woridng  Group 

Common  Ada  XV^ndow  Interface 

Command,  Control,  and  Intelligence 

Internadtmal  Consultative  Committee  for  Telegrsqrti  and 

TelqriKxie 

Code  Counting  Program 

Combat  Control  System 

Central  Design  A^ivity 

Central  Data  Base 

CASE  Data  Interchange  Format 

Central  Design  Programming  Activity 

Critical  Design  Review 

Ckmtract  Data  Requirements  List 

Communications  Qectronics  Command 

Computer  Emergency  Re^nse  Team 

Computer  Emergency  Re^nse  Team  Coordination  Ccntm^ 

Contractor-Furnished  Equipment 

Computer  Graphics  Interfere 

Computer  Grsy)hics  Metafile 

Configuration  Item 

Central  Issue  Facility 

Corporate  Information  Management 

Connectionless  NetWOTk  Protocol 

Compiled/Assembled  Lines  of  Code 

Cqnbility  Maturity  Model 

CoMPldeness 

Compiler  Monitor  System-2 

Carnqgie-MeUmi  University 

Cain^ie-Mdlon  Univashy/Software  Engineering  Institute 

Chief  of  Naval  Operations 

Commcm  Butiness  Oriented  Language 

Common  Operating  Environment 

Cost  and  Operational  Effectiveness  Analysis 

Commander,  Naval  Computer  and  Telecommunications 

Command 

Commander,  Space  and  Naval  Warfare  Systems  Command 
C(mcq>t  of  Operations 

Common  Object  Request  Broker  Architecture 
Commerdal  Off-lhe-Shelf 
Computer  Program  Development  Laboratory 
Command  Program  Processor 
Competitive  Prototyping  Strata 
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CPU 

CRADA 

CREASE 

CRISD 

CRLCMP 

CRM 

CRSS 

CRWG 

CSC 

csa 

CSRO 

CSS 

CSS 

csu 

CWG 

D&V 

DAB 

DACS 

DAR 

DARPA 

DAT 

DBMS 

DC 

DCDS 

DCE 

DCP 

DDI 

DDN 

DDR&E 

DDRS 

DEI 

DEM 

DEMVAL 

DFCS 

DFU 

DID 

DISA 

DMRD 

DOD 

DODD 


Central  Processing  Unit 

Cooperative  Reseaidi  and  Developnient  Agreement 
Catalog  of  Resources  for  Education  in  Ada  and  Software 
Engineering 

Computer  Resource  Int^iated  Software  Document 
ComiHiter  Resources  Life-Cycle  Management  Plan 
Computer  Resources  Management 
C3I  Reusable  Software  System 
Computer  Resources  Working  Group 
Computer  Sciences  Corporation 
Computer  Software  Configuration  Item 
Center  for  Software  Reuse  Operations 
Centralized  Structure  Store 
Computer  Sciences  Sdiool 
Computer  Software  Unit 
Coordinator  Working  Group 

Demcmstraticm  &  Validation 

Defense  Acquisition  Board 

Data  and  Analysis  Center  for  Software 

Defense  Acquisition  R^ulations 

Defense  Advanced  Research  Projects  Agency 

Digital  Audio  Tape 

Database  Management  System 

Device  Coordinate 

Distributed  Computing  Deagn  System 
Distributed  Computing  Environment 
Decision  Coordinating  Psq)er 
Directorate  of  Defense  Information 
Defense  Data  Network 

Director  of  Defense  Research  and  Engineering 

DOD  Data  Rqmsitory  System 

Data  Elements  in  tiie  Source 

Digitized  Electronic  Module 

Demonstration  and  Validation 

Digital  Flight  Control  System 

De  Facto  Usage 

Data  Item  Description 

Defense  Information  Systems  Agency 

Defense  Management  Review  Decision 

Dqnrtment  of  Defense 

DqMUtment  of  Defense  Directive 
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DODl 

Dqwrtment  of  Defense  Initiative 

DON 

Dqnrtment  of  the  Navy 

DPI 

Data  Processing  Installation 

DP/DGU 

Distributed  Processor/Di^lay  Generator  Unit 

DRPM 

Direct  RqMirting  Program  Manager 

DS 

Directory  Service 

DSRS 

Defense  Software  Rqx)sitory  System 

DTC2 

Desk  Top  Computer  2 

DTN 

Data  Transfer  Ndwork 

DTIC 

Defense  Technical  Information  Center 

DUS 

Design  Unit  Spedfication 

DWS 

Defensive  Weaptm  System 

ECCM 

Electronic  Counter-Countermeasures 

ECLD 

Embedded  Comment  Lines  in  Data 

ECLS 

Embedded  Comment  Lines  in  Source 

ECM 

Electronic  Countermeasures 

ECMA 

European  Computer  Manufacturing  Association 

ECS 

Electronic  Customer  Services 

EDI 

Electronic  Data  Interdumge 

EDL 

Event-Driven  Language 

EDSI 

Equivalent  Delivered  Source  Instructions 

EMPM 

Electronic  Manuscri|H  Prqiaration  and  Markup 

EMR 

Extended  hfemory  Readr 

ENB 

Engineering  Notdrook 

EPROM 

Erasable  Prxrgrammable  Read  Only  Memory 

EP 

Enhanced  Processor 

ERA 

EntiQr  Relaticmdiip  Attribute  " 

ESD 

Electronic  Systmns  Division 

ESM 

Electronic  Support  Measure 

4GL 

Fourth  Generation  Language 

FAA 

Federal  Aviation  Administratirm 

FAR 

Federal  Acquiation  Emulations 

FAU 

Fin  Actuator  Unit 

FCDSSA 

Fleet  Combat  Direction  System  Support  Activity 

FD 

Functional  Descriptitm 

FE 

Functional  Element 

FFP 

Firm  Fixed  Price 

FFRDC 

Federally  Funded  Research  and  Devdopment  Center 

FIFO 

First  In  First  Out 
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FIPS 

Federal  Information  Processing  Standards 

Fir 

Flight  Instrument  Trainer 

FMSO 

Fleet  Material  Support  Office 

FP 

Function  Point 

FPI 

Functional  Process  Improvement 

FRAWG 

Front  Range  Ada  Woiidng  Group 

FSD 

Full-Scale  Development 

FTAM 

File  Transfer,  Access,  and  Management 

FTP 

File  Transfer  Program 

ftp 

File  Transfer  Protocol 

43RSS 

ANAJYK-43(V)  Run-Time  Support  System 

GAO 

General  Accounting  Office 

GB 

Gigabyte 

GEU 

Guidance  Electronics  Unit 

GFE 

Govemment-Fumistod  Equipment 

GFS 

Government-Furnished  Software 

GIS 

Geognqdiic  Informadmi  System 

GKS 

Gnqriu^  Kernel  System 

GM 

Global  Memory 

GNCP 

Guidance,  Itovigation,  and  Control  Program 

GNMP 

Government  Network  Management  Profile 

GOSIP 

Government  Open  Sy^ems  Interconnectimi  Profile 

GOTS 

Govemment-Off-the-Shdf 

GPEF 

Generic  Package  of  Elementary  Functirms 

GPPF 

Generic  Package  of  Primitive  Functions 

GPO 

Government  Printing  Office 

GRACE™ 

Generic  Reusable  Ada  Components  for  Engineering 

GSIS 

Grtqihics  System  Interface  Standard 

GTRIMS 

Gro^  Controller  'Daining  System 

GUI 

Gr3q>hical  User  Interface 

HOL 

High  Order  Language 

HP 

Hewlett-Packard 

HP  VUE 

Hewlett-Packard  Visual  User  Environment 

HPBP 

EQgh-Performance  Baclq>lane 

HPP 

High-Performance  Processor 

IBM 

International  Buaness  Machines 

I-CASE 

Int^rated  Computer-Aided  Software  Engineering 

ICC 

Irvine  Comjriler  Corporation 

ICE 

Indq)endent  Cost  Estimate 
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n>EF 

Intended  System  Definition  Language 

lEC 

Intematioiial  Etoctro-Technical  Committee 

IEEE 

Institute  of  Electrkal  and  Electronics  Engineers 

IGES 

Initial  Gr^Aics  Exdumge  Specification 

IGRV 

Inqnoved  Guard  Rail  Five 

ILS 

Intqpnted  Logistics  Support 

JLSP 

Int^rated  Logistics  Support  Plan 

IMU 

Inertial  Measurement  Unit 

INEL 

Idaho  ^btional  Engineering  Laboratory 

INFOSEC 

Information  System  Security 

InProc 

In  Processing 

I/O 

Input/Outyut 

IOC 

Initial  Operating  Cqjability 

lOP 

Iiqmt/OuQMit  Processes 

IPO 

Information  Planning  and  Organizing 

IPR 

In-Process  Review 

IPS 

Imitated  Prcgect  Summary 

IPSE 

Int^rated  Prqject  Support  Environment 

IRAC 

International  Requirements  and  Design  Criteria 

IRDS 

Information  Resmirce  Dictionary  System 

KM 

Information  Resources  Management 

KS 

Interfooe  Requirements  Specification 

IS 

Information  System 

ISA 

Instruction  Set  Architecture 

ISC 

Iiqxit  Signal  Conditioner 

ISDN 

Int^rated  Services  Digital  Networic 

ISEA 

In-Service  Engineering  Activity 

ISEE 

Int^rated  Software  Engineering  Environment 

ISO 

International  Organization  for  Standardization 

ISSC 

Information  System  Software  Center 

ITPB 

Information  Technology  Policy  Board 

rrs 

Int^rated  Test  Softwm 

IV&V 

Independent  Verification  and  Validation 

JCS 

Jdnt  Chiefii  of  Staff 

JIAWG 

Joint  Integrated  Avionics  Working  Group 

JIEO 

Joint  Interoperability  and  Engineering  Organization 

JLC-JPCG-CRM 

Joint  Logisto  Cmnmanders  Joint  Policy  Coordinating 
Group  on  Computer  Resources  Management 

JTC 

Joint  Tedinical  Committee 
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K 

1.000 

KAPSE 

Kend  Acb  Prognmming  Support  Environment 

LAN 

Local  Area  Network 

LCM 

Life-Cycle  Management 

LCSA 

Life-Cycle  Siq)port  Activity 

LOC 

Level  of  Conansus 

LRFP 

Logistics  Requirements  Funding  Plan 

MAPSE 

Minimal  Ada  Programming  Siqjport  Environment 

MAT 

MATuiity 

MB 

M^abyte 

MCCDC 

Marine  Qnps  Combat  Development  Command 

MCCR 

Nfission-Critical  Conqxiter  Resources 

MCCRES 

Marine  Corps  Combat  Readiness  Evaluation  System 

MCO 

Marine  Cmps  Order 

MENS 

Kfission  Elonent  Need  Statement 

MEPS 

Message  Edit  Processing  System 

MHS 

Message  Handling  Service 

MIL-HDBK 

Military  Handbook 

MIL-STD 

bfilitary  Standard 

MBMMS 

Marine  Corps  bit^rated  Maintenance  Management  System 

MIPS 

NGllions  of  Instructions  per  Second 

MIS 

Management  Information  System 

mm 

Millimeter 

MMI 

Man-bfediine  Interfece 

MMS 

bfinimum  Mode  Software 

MOA 

Memorandum  of  Agreement 

MOTS 

Military  Off-The-Shdf 

MSE 

Master’s  in  Software  Engineering 

MT 

bfisaon  Trainer 

NA 

Netwmk  AdqMor 

NAC 

Naval  Avionics  Center 

NADC 

Naval  Air  Devdoinnent  Center 

NAn 

North  American  Portable  Common  Tool  Environment 
Liitiative 

NAPUO 

Nbrdi  American  PCTE  User’s  Groiq> 

NARDAC 

Ifevy  Regional  Data  Automation  Center 

NASA 

National  Aeronautics  and  Space  Administratitm 

NASEE 

NAVAIR  Software  Engine^g  Environment 

NATO 

North  Atlantic  Treaty  Organization 
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Acronyms  and  Abbroviaiions 


NAUG 

Navy  Ada  Users  Group 

NAVAIR 

Naval  Air  Systems  Command 

NAVCOMTELCOM 

Iteval  Cooqwter  and  Telecommunicaticms  Command 

NAVDAC 

Navy  Data  Automation  Command 

NAVSEA 

Naval  Sea  Systems  Ccmunand 

NAVSUP 

Mtval  Simply  Systems  Command 

NAVSWC 

Ntaval  Surfitte  War&ie  Center 

NAWC-AD-WAR 

Naval  Air  Warfue  Center.  Aircraft  Division,  Warminster 

NCA 

Naval  Center  for  Cost  Analyses 

NCCOSC 

Iteval  Ccnnmand,  Control,  and  Ocean  Surveillanoe  Center 

NCS 

Network  Computing  Service 

NCTAMS 

Naval  Conqxiter  and  Telecommunications  Area  Master 
Station 

NCTAMSLANT 

NCTAMS  Atlantic 

NCTAMS  EASTPAC 

NCTAMS  Eastern  Pacific 

NCTC 

Naval  Computer  and  Tdecommunications  Command 

NCTS 

Naval  Computer  and  Telecommunications  Station 

NDC 

Normalized  Device  Coordinate 

NDI 

Nondevdopmental  Item 

NGCR 

Neat  Generation  Computer  Resources 

NISBS 

NATO  Interoperabte  Submarine  Broadcast  System 

NIST 

National  Institute  of  Standards  and  Technology 

NISMC 

Naval  Informatiai  Systmn  Management  Center 

NISO 

National  Information  Standards  Organization 

NIUF 

North  American  ISDN  Users’  Forum 

NM 

Netwtnk  Management 

NOSC 

Iteval  Ocean  Systems  Center 

NRaD 

Naval  Reseaidi  and  Development 

NSWC 

Naval  Surfoce  Weapons  Center 

NTCSS 

Naval  Tactical  Con^  Support  System 

NTIS 

National  Tedinical  Informatitm  S^ce 

NTSC 

Navy  Training  and  Simulation  Center 

NUSC 

Naval  Undersea  Comnnand 

NWRC 

Navy  Wide  Reuse  Center 

NWSUS 

Navy  WWMCCS  Site-Unique  Software 

OAS 

Offensive  Avionics  System 

OA5D 

Office  of  the  Assistant  Secr^ary  of  Defense 

OCD 

Operational  Concqpt  Document 

OFPS 

Operational  Flight  Program  Size 

OMG 

Object  Management  Groiq) 

OMU 

Operational  Mock-iq> 

Acronyms  and  Abbrcviatiom 

1 

1 

OOD 

Obje^-Oriented  Design 

a 

OOP 

OI)|iect<Orienied  Prognmming 

1 

OORA 

Object-Oriented  Requirenients  Analysu 

■ 

OPE 

Open  Systenu  Enviiooment 

■ 

OPNAVINST 

Itaval  Opeiatians  Instruction 

1 

OPR 

Office  of  Primaiy  Responsibility 

■ 

ORG 

Ofgimization  Chain  Coninutnd 

■ 

OS 

OpeiatiQg  System 

1 

OSA 

C^ien  Systems  Architecture 

OSD 

Office  of  the  Secretary  of  Defense 

■ 

OSE 

Open  Systems  Environment 

1 

OSF 

Open  Software  Foundation 

OSI 

C^ien  Systems  Intoconnecticm 

■ 

OSISL 

C^ien  Systems  Interftoe  Standards  List 

1 

OSS 

(iterations  Siqiport  Systran 

OSSWG 

Operating  Syttm  Standards  Working  Group 

1 

PAV 

Product  Availability 

PC 

Personal  Computer 

1 

PCIS 

Portable  Common  Interfiice  Set 

■ 

PCTE 

Portable  (Common  Tool  Environment 

PDL 

Fmgiam  Design  Language 

1 

PDR 

Prdfirninary  Derign  Review 

PDS 

Post-Deployment  Support 

PDSS 

Post-Dqtloyment  Sof^vare  Suj^xnt 

1 

PDU 

Pulse  Driver  Unit 

■ 

PEO 

Program  Executive  Office 

PHIGS 

Programmer's  ffierardiical  Interactive  Graphics  System 

1 

pn 

Protocol  Indqtendent  Interface 

PIMB 

PCTE  Interface  Management  Board 

PIWG 

Performance  Issues  Woridng  Group 

1 

PMC 

Project  Management  Charter 

POC 

Ptrint  of  Contact 

■ 

POM 

Program  CX>jecdve  Memorandum 

1 

POSDC 

Portable  Operating  Syriem  Interface  for  Computer  Systems 

PPBS 

Hanning,  Programming,  and  Budgeting  System 

■ 

PRISM 

Portable  Reusable  Int^rated  Software  Modules 

1 

PRL 

FRoblems/Limitations 

PRR 

Product  Readiness  Review 

■ 

PSE 

Project  (or  Programming)  Support  Environment 

1 

PSERM 

Project  Support  Environment  Reference  Modd 

PSESWG 

Project  Support  Envirmiment  Standard  Working  Group 

1 
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Acronym  and  Abbreviations 


PSA 

Progrun  Structure  Analysis 

PSL 

Program  Structure  Language 

QA 

Quality  Assurance 

RAD 

Research  and  Devdopment 

RACS 

Registiatian  and  Access  Control  System 

RADC 

Requirements  and  Design  Criteria 

RAM 

RandiMn  Access  Memory 

RAPID 

PeiiMhlg  Ada  Prodi^  for  Information  Systems 
Devdopment 

RCL 

RAPID  Center  Library 

RDA 

Remote  Database  Access 

RDBMS 

Relational  Database  Management  System 

RDT&E 

Research,  Devdopment,  Test,  and  Evaluation 

RES 

Resources 

REVIC 

Revised  Intermediate  COCOMO 

RFP 

Request  for  Proposals 

RLF 

Reuse  Library  Framework 

RLT 

Reuse  library  Todset 

RMA 

Rate  Monotonic  Analysis 

RMC 

Reooofiguiable  Missiem  Computer 

ROI 

Return  on  Investment 

ROM 

Read  Only  Memory 

RPC 

Rnnote  Process  Communication 

RPC 

Remote  Procedure  Call 

RSC 

Reusable  (Ada)  Software  Component 

RTAda 

Run-Time  Ada 

RTE 

Run-Time  Environment 

SAE 

Software  Architectures  Engineering 

SAFENET 

Survivable  Adaptable  Fiber-optic  Embedded  Network 

SAI 

Software  Actiem  Item 

SAIL 

System  Avionics  Int^ration  Laboratory 

SAME 

SQL  Ada  Module  Extension 

SAMeDL 

SQL  Ada  Module  Description  Language 

SASET 

Software  Ardiitecture  Sizing  and  Estimating  Tool 

SASSY 

Supported  Activities  Sujqrly  System 

SCAI 

Space  Command  &  Control  Ardiitecture  Infrastructure 

sees 

Submarine  Combat  Ctmtrol  System 

SCE 

Software  Capability  Evaluation 

SCH 

Scheduler 

Ada  bnpiamMitation  GuMa 
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Acronym  and  Abbreviations 


SCL 

Stand-alone  Comment  Lines 

SCMP 

System  Coniiguiatimi  Management  Plan 

SCP 

System  Concept  Paper 

SCRB 

Software  Change  Review  Board 

SCS 

Submarine  Combat  System 

SDC-W 

Software  Development  Center,  Washingttm 

SDD 

System  Design  Definition 

SDE 

Software  Development  Environment 

SDF 

Software  Devdopment  Folder 

SDIO 

Strat^ic  Defense  Initiative  Organization 

SDL 

Software  Devdopment  Laboratory 

SDP 

Software  Devde^nwnt  Plan 

SDP 

System  Division  Paper 

SDR 

System  Design  Rev^ 

SDSR 

Software  Devdopment  Status  Rqxm 

SDTS 

Spatial  Data  Transfer  Standard 

SECNAVINST 

Secretary  of  the  Navy  Instruction 

SECNAVNOTE 

Secretary  of  the  Navy  Note 

SECR 

Standard  Embedded  Computer  Resource 

SEE 

Software  En^eering  Environment 

SEI 

Software  Engineering  Institute 

SEM 

Standard  Electronic  Module 

SEMP 

System  Engineering  Management  Plan 

SEO 

Software  Executive  Official 

SEOC 

Software  Executive  Offidal  Council 

SEPG 

Software  Engineering  Process  Group 

SES 

Senior  Executive  Service 

SGS/AC 

Shipboard  Gridlock  System  with  Auto<U>rrdation 

SGML 

Standard  Generalized  Maricup  Language 

SIGAda 

Special  Interest  Group  cm  Ada 

SIGSOFT 

Special  Interest  Group  cm  Software  Engineering 

SIL 

System  integratiem  Laboratory 

SIP 

System  Int^raticm  Plan 

SISTO 

Software  and  Intdligent  Systems  Technolc^  Office 

SLCMP 

Software  Life-Cycle  Management  Plan 

SLOG 

ScNitoe  Lines  of  Code 

SLOC7SM 

Source  Lines  of  Code  pm*  Staff  Month 

SLOewe 

Source  Lines  of  Code  ^^tiiout  Comments 

SMB 

Submarine  Message  Buffer 

SMM 

Software  Management  Metrics 

SMP 

Serftware  Master  Plan 

SOW 

Statement  of  Work 
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SPA 

Software  Process  Assessment 

SPAWAR 

Space  and  Naval  Warfare  Systems  Command 

SPC 

Software  Productivity  Consortium 

SPD 

Software  Process  Definition 

SPDL 

Standard  Page  Description  Language 

SPI 

Software  Process  Improvement 

SPO 

System  Programming  Office 

SPR 

Software  Problem  Rqxm 

SQAP 

Software  Quality  Assurance  Plan 

SQL 

Structured  Query  Language 

SRC 

Software  Requirements  Change 

SRP 

Software  Reuse  Program 

SRR 

Software  Requiren^ts  Review 

SRS 

Software  Requirements  Specification 

SSA 

Software  Support  Activity 

SSC 

System  Supp^  Center 

SSS 

System/S^ment  Specification 

STANHNS 

Standard  Financial  System 

STANHNS-R 

Standard  Financial  System  Redesign 

STARFIARS 

Standard  Army  Financial  Accounting  and  Rqxnting  System 

STARS 

Software  Tecimology  for  A(hq>table,  Reliable  Systems 

STB 

STaBUity 

STC 

Software  Technology  Confoence 

STEP 

Standard  for  the  Exchange  of  Product  Modd  Data 

sn 

Software  Technolc^  Initiative 

STSC 

Software  Technology  Support  Center 

SUP 

Support  Planning 

SWAP 

Software  Action  Plan 

SWAP-WG 

Software  Action  Plan  Working  Group 

SWG 

Special  Worldng  Gnnip 

SWTP 

Software  Technology  Plan 

SYSCOM 

Systems  Command 

TAC 

Tactical  Advanced  Computer 

TACAMO 

Take  Charge  and  Move  Out 

TACFIRE 

Tactical  Fire  Directicxi 

TAFIM 

Tedinical  Architecture  For  Information  Management 

TADSTAND 

Tactical  Digital  Standard 

TAMPS 

Tactical  Aircraft  Mission  Planning  System 

TC 

Target  C^»city 

TC 

Technical  Committee 

TCL 

Total  Comment  Lines 

Ada  implainantation  GuMa 
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Acronyms  and  Abbreviations 


TCP/IP 

Transmission  Control  Protocol/lntemet  Protocol 

TD 

Technical  Directive 

TDA 

Technical  Directive  Audiority 

TDT 

Theater  Diq>lay  Terminal 

T&E 

Testing  and  Equation 

TdeAdaEXEC 

Telesoft  Run-Time  Environment 

TEMP 

Test  and  Evaluation  Master  Plan 

TEP 

Test  and  Evaluation  Plan 

TFA 

Transparent  Access 

TLCSC/LLCSC 

Top  Level/Lower  Levd  Computer  Software  Component 

TLOC 

Total  Lines  of  Code 

TOES 

Telqriione  Order-Entry  System 

TOPS 

Training  and  Operations  Section 

TQM 

Total  Quality  Management 

TSGCEE 

Tri-Service  Group  on  Communications  and  Electronics 
Equipment 

UIMS 

User  Interface  Management  System 

ULLS 

Unit  Level  Logistics  System 

USMC 

U.S.  Marine  Corps 

USTAG 

United  States  Teduiical  Advisory  Group 

USW 

Undersea  Warfare 

UUT 

Unit  Under  Test 

VADS 

Verdix  Ada  Devdopment  System 

VDI 

Virtual  Device  Interface 

VHSIC 

Very  Ifigh-Speed  Integrated  Circuit 

VRC 

Virtual  Reference  Coordinate 

VSR 

Validation  Summary  Rqx>rt 

VT 

Virtual  Terminal 

VUE 

Visual  User  Environment 

WAdaS 

Washingttm  Ada  Symposium 

WAM 

WWMCCS  ADP  Modernization 

WBS 

Work  Breakdown  Structure 

we 

World  Coordinate 

WFNIA 

Wdls  Fargo  hnkko  Investment  Advisors 

WIS 

WWMCCS  Information  System 

WST 

Weqxm  System  Trails 

WPAFB 

Wri^t  Patterson  Air  Force  Base 

WWMCCS 

World  Military  Command  and  Control  System 
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